Issue 125111 - Huge memory usage with docs which contain many graphics
Summary: Huge memory usage with docs which contain many graphics
Alias: None
Product: Writer
Classification: Application
Component: editing (show other issues)
Version: 4.2.0-dev
Hardware: All Windows, all
: P3 Normal (vote)
Target Milestone: 4.1.1
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2014-06-18 10:45 UTC by Armin Le Grand
Modified: 2017-05-20 10:35 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---
jsc: 4.1.1_release_blocker+


Note You need to log in before you can comment on or make changes to this issue.
Description Armin Le Grand 2014-06-18 10:45:07 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 (, same as mentioned in issue 125000 first comment.
Comment 1 Armin Le Grand 2014-06-18 10:50:40 UTC
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.
Comment 2 Armin Le Grand 2014-06-18 11:02:43 UTC
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...
Comment 3 Armin Le Grand 2014-06-18 15:00:24 UTC
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...
Comment 4 Armin Le Grand 2014-06-19 11:34:18 UTC
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...
Comment 5 Armin Le Grand 2014-06-19 12:41:02 UTC
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...
Comment 6 Armin Le Grand 2014-06-19 16:45:41 UTC
Okay, linux 32bit check in progress, commiting changes
Comment 7 SVN Robot 2014-06-19 16:54:14 UTC
"alg" committed SVN revision 1603941 into trunk:
i125111 limit mem footprint for GraphicObjects in 32Bit environments
Comment 8 Armin Le Grand 2014-06-20 10:22:51 UTC
Linux 32bit test done, all works as expected.
Comment 9 Oliver-Rainer Wittmann 2014-06-23 09:02:42 UTC
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.
Comment 10 jsc 2014-06-23 09:07:57 UTC
grant showstopper fix
Comment 11 Armin Le Grand 2014-06-23 09:38:17 UTC
Okay, preparing integration to AOO410 branch codeline...
Comment 12 Armin Le Grand 2014-06-23 09:42:08 UTC
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.
Comment 13 Armin Le Grand 2014-06-23 16:42:29 UTC
Merging changes to AOO411, testing built version...
Comment 14 SVN Robot 2014-06-23 16:51:39 UTC
"alg" committed SVN revision 1604874 into branches/AOO410:
i125111 limit mem footprint for GraphicObjects in 32Bit environments
Comment 15 Armin Le Grand 2014-06-23 17:05:36 UTC
Changes added to AOO411, okay, done.
Comment 16 fanyuzhen 2014-07-08 16:20:49 UTC
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 ( 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.
Comment 17 fanyuzhen 2014-07-11 02:05:21 UTC
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 (, it works well, and no crash.
Comment 18 JZA 2014-07-17 21:25:47 UTC
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.
Comment 19 fanyuzhen 2014-07-18 03:48:16 UTC
Thanks Alexandro for your checking on Linux.
It's verified fixed based on comment 16, 17 and 18.
Comment 20 Oliver-Rainer Wittmann 2014-07-18 12:13:38 UTC
reverting jza change to make this issue public again.