TRichView.com

Hi There,

I've got a problem that occurs with one of our clients using large images in the header and footer of their documents. When the document is opened, typing a simple sentence can take up to a minute as the keystrokes are slowed down considerably.

The client requires the high quality images so that it looks good when printed.

I can reproduce this problem using RichViewActionsTest by doing the following:
1. Create a new document
2. Type a sentence into the body. (ie. "Test Test Test"
3. Double click on the header and insert a large image.
(The header in our case is 6201x1240 pixels, saved at image quality 10, resulting in a file of size 408KB)
4. Double click on the footer and insert a large image.
(The header in our case is 8858x827 pixels, also saved at image quality 10, resulting in a file of size 346KB)
5. At this stage there's no issue. Double clicking in the body and typing "Test Test Test" works fine.
6. Save the file as RVF
7. Click RichViewActionsTest and reopen
8. Open the file just saved
9. Type a sentence into the body
Each character typed takes 1-3 seconds to appear.

Interestingly enough if I follow the same steps as above, but insert the same two pictures into the body instead, there's no performance issue.

Note that when I reduced the image sizes to a quarter of the size (using photoshop) and then inserted them in, it was still slow.

I'm using Version 7.3.2 of ScaleRichView with Version 16.7.1 of RichView on Delphi 2010. I can upload an example RVF if that helps.

Apart from asking the client to reduce the image size or changing the format, can you recommend any suggestions, settings, workarounds, fixes or tweaks?

Kind Regards,

Dave

Please send RVF file to richviewgmailcom.
The picture format (png or jpeg?) is important, and whether the picture is scaled down (by default, scaled TPngImage is shown as it is, but for TJpegImage, a scaled preview thumbnail is created).

But I am afraid I will be able to look at this example only after September , 4th, I am going on a vacation. I'll continue to answer to questions while out of office, but I will not be able to debug and to profile applications, sorry.

Hi Sergey,

Thanks for your quick response. I've sent the rvf through to richview@gmail.com . The images are coded as jpegs.
Hope you have a brilliant vacation, and I look forward to hearing from you when you get back...

Cheers,

Dave

We happened to meet this problem, but we compressed our images from about 200kb to 30kb, then problem was gone.
I did some debug. Perhaps , it has something to do with saving header data to memory stream and loading from memory stream.

The problem only started occurring after we upgraded to the latest versions of ScaleRichView (7.3.2) and RichView (16.7.1).

The older version loaded the large header/footer images without any lag.

I found that when we did reduce the size of the images by a quarter, it did help a little bit, but typing in the editor after loading was still slow.

Hope that helps...

Working with headers and footers was changed in recent versions, since they now support 6 types of header/footers, with still only two internal editors (RVHeader and RVFooter) for displaying them.

Sorry, I did not tested this problem yet, since we busy releasing Report Workshop and updates. I'll check it ASAP, in this week.

Hi Sergey, Any luck with resolving this issue?

Yes, sorry for the delay.

The problem was caused by moving documents in the header between SubDocuments[] and RVHeader (the same for footer). Normally, this procedure is lightening-fast, but in your document headers contain huge jpeg images, and the component needs to re-create a thumbnail for them to provide high-quality scaling.
TSRichViewEdit can cache one of headers and footers, but in the current version this cache is activated for the last edited header/footer, so initially it does not work.

Solution (will be included in the next update):
- open SclRView.pas
- add at the end of TSRichViewEdit.Format:

Thank you so much Sergey! Very much appreciated. That seems to have fixed the issue!

This change is included in ScaleRichView 7.6.1 (available for registered users)