Problems with many images inside TRichView

[azabluda]

Hello,

We are using RichView 14.0.3 in our project, and since recently we observe some strange and irregular behavior (EAccessViolation's, hangups, empty rich content, etc.) obviously caused by the general growth the documents we have to display. After some investigation we narrowed down the problem to the number of images within the document.

To exclude all unrelated factors we generated a simple RTF document https://dl.dropboxusercontent.com/u/893 ... images.rtf which consist of many small images. We can easily open it in MS Word 2013.


The official demo application http://www.trichview.com/resources/acti ... ontest.zip (as of October 31, 2013) however just becomes non-responsive without displaying any clear error message.


Apparently RV attempts to allocate all GDI objects for all images at the time. In most applications this is rather pointless, as one would expect only as many GDI objects as needed for rendering the currently visible area (usually one page) or drawing a page on a given canvas (exactly our scenario).

Another annoying issue is that RV apparently "swallows" the OS-exceptions, which makes it rather difficult to diagnose the problem.

Best Regards,
Alexander

[Sergey Tkachenko]

Yes, the current version of TRichView allocates TGraphic objects for all images in documents. There are scenarios for resource economy for identical pictures, but there is no general solution.

Restoring TGraphic from stream is a costly operation, so solution must be smart. It is planned for future, but not for very near future, sorry.

TRichView does not hide exceptions completely - if it occurs on drawing, it shows it in the top left corner of the window, to prevent endless displaying of dialog boxes.

[azabluda]

Sergey, thank you for the swift reply!

One naive idea has crossed my mind. As the TGraphic class is just a pure abstraction, may there exist implementations which internally don't allocate any GDI object unless absolutely necessary, e.g. only for rendering? We can tolerate the implied costs, because normally we only need to render one page at the time which doesn't contain too many images. After the page is rendered the allocated GDI handles are to be disposed of course.

Have you heard of any implementation like this? Do you expect it to be difficult to implement in RV? Any advise would be highly appreciated. Thanks!

if it occurs on drawing, it shows it in the top left corner of the window, to prevent endless displaying of dialog boxes

Apparently with our syntactic RTF document the app just didn't reach the drawing procedure yet. Therefore no messages in the top left corner.

[Sergey Tkachenko]

Unfortunately, I do not have such TGraphic class.

I see the solution in storing image data in TMemoryStream, creating TGraphic object on request, using a cache for not decreasing performance too much.
Unfortunately, this change requires an extensive testing, and currently we do not have time for this

RTF reading is really in try..catch, so exception are visible only in IDE.

[EvRenesse]

Hi,

is this problem solved in the current version?

Under Windows 10 it is no longer possible to increase the maximum number of GDI handles by changing the value of GDIProcessHandleQuota in the registry. The value can be changed, but without any effect after restarting the computer. So large documents with lots of images can not be handled further more under Windows 10.

EvRenesse

[Sergey Tkachenko]

This work is still in progress, sorry. I hope to release a version that can limit a number of gdi handles in a week or two.