Apache OpenOffice (AOO) Bugzilla – Issue 125111
Huge memory usage with docs which contain many graphics
Last modified: 2017-05-20 10:35:42 UTC
This is a follow-up to issue 125000 and issue 124999. There, involved crasches were fixed. Still a huge memory consumption happens during paints. There is no memory leak (it gets freed after paints) but not all graphics may be shown correctly (not a permanent effect). As bugdoc, please use the one from issue 118725, comment 13 (https://issues.apache.org/ooo/show_bug.cgi?id=118725#c13), same as mentioned in issue 125000 first comment.
As mentioned in issues 125000 and 124999 the basic reason is to use the new primitive graphic handling possibilities for better quality, or better no longer using the old ones from the GraphicManager. The problem is not the GDI+ usages, but more the limited memory when running on 32bit (as on win currently, thus win only). During big paints e.g. PagePreview there are simply no timer events which may swap out graphics during that phase, thus the memory is in danger to run out. This has never been handled in the involved mechanisms in the past (GraphicManager/GraphicObject), but did not happen in Writer due to it's own special solution using the GraphicManager paints. In the other apps this could happen but is difficult to produce (Draw/Impress would need enough pics on one page, Calc on one sheet). The plan is (for now) to add a memory consumption watch for GraphicManager for 32bit systems to avoid this situation by starting to swap out GraphicObjects in that situation.
Added the same fix to WinSalBitmap::ImplCreateGdiPlusBitmap as already applied to WinSalBitmap::ImplCreateGdiPlusBitmap, secure new Gdiplus::Bitmap calls with checking the result. Added getCacheTimeInMs() to init the SwGrfNode swap out times to be user-defined (from settings) in the same way as in the other apps (same as iused in svx). Looking how to detect/handle memory footprint of managed GraphicObjects in GraphicManager, in best case at a central place in GraphicManager itself...
Added code to reset the timer (kind of touch for buffer entries) so that the SwapOutTimer can be restarted when the GraphicObject was used. This was initially in the GraphicManager draw stuff. If not doing this SwapOut would be called in fixed time intervals, independent from usage. I have now a working solution, but need to experiment with the upper memory bounds in a pro win 32bit build to ensure functionality...
Checked that 64bit versions work as expected (mac pro build). Checked that Draw/Impress and Calc work with that changes unchanged on 32bit and 64bit systems. Weighted the maximum memory bound to work well on 32Bit Windows system, made dependent of user settings in tools/options/memory. Doing some more experiments on the Win 32bit version...
Did some tests with the Writer bugdoc, Draw/Impress and Calc opened, all with huge added bitmap graphics, works pretty well now. Waiting for the linux version to finish and do some checks...
Okay, linux 32bit check in progress, commiting changes
"alg" committed SVN revision 1603941 into trunk: i125111 limit mem footprint for GraphicObjects in 32Bit environments
Linux 32bit test done, all works as expected.
I have reviewed the code changes: - Some important improvements/corrections for the fixes made for issue 124999 and issue 125000. - Code to limit memory footprint by 'swapped-in' <GraphicObject> instances looks good. --> should be a candidate for planned 4.1.1 - any further thoughts.
grant showstopper fix
Okay, preparing integration to AOO410 branch codeline...
Before it gets overseen, the r1604028 (needed to move sort functor out of function scope) also needs to be included, but contains no semantic changes.
Merging changes to AOO411, testing built version...
"alg" committed SVN revision 1604874 into branches/AOO410: i125111 limit mem footprint for GraphicObjects in 32Bit environments
Changes added to AOO411, okay, done.
Checked it with build AOO411m1(Build:9770) - Rev. 1603804 2014-06-16 14:10:45 (Mo, 16 Jun 2014) on Windows 32bit version, opening bugdoc from issue 118725, comment 13 (https://issues.apache.org/ooo/show_bug.cgi?id=118725#c13) will rise Memory consumption by 2.3 MB or so, no crash. My PC: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHZ 1.97 GHz, 2.98 GB of RAM. Need check on Mac and Linux.
Checked it with build AOO411m1(Build:9770) - Rev. 1603804 2014-06-16 14:10:45 (Mo, 16 Jun 2014) on Mac 10.9.3, opening bugdoc from issue 118725, comment 13 (https://issues.apache.org/ooo/show_bug.cgi?id=118725#c13), it works well, and no crash.
AOO411m1(Build:9770) - Rev. 160380 2014-06-19 10:08 - Linux i686 Test the bugdoc on an Intel(R) Core(TM)2 Solo CPU U3500 @ 1.40GHz Memory 4GB RAM. Document opened correctly, no crashes, images displayed well.
Thanks Alexandro for your checking on Linux. It's verified fixed based on comment 16, 17 and 18.
reverting jza change to make this issue public again.