| 2014-03-14 10:51:32 |
su_v |
description |
Compared to current stable, the new cairo-based renderer seems to have always had a much higher memory usage when zooming in closely on objects with a pattern fill based on a large embedded bitmap image. Lately however, the memory usage when zooming in closely seems to have nearly tripled.
Steps to reproduce [1]:
1) launch current trunk with default (new) prefs
2) open the attached file
3) open a system utility which allows to monitor memory usage
4) select the only path in the file
5) zoom to selection '3'
--> memory usage "explodes"
6) zoom to page '5'
--> memory usage immediately reverts to prior level
Sample data (same steps with minimal test case, OS X 10.7.5, 8 GB RAM):
0.48.x r10015: ~ 170 MB real
0.48+devel rev <= 12823: ~ 760 MB real
0.48+devel rev >= 12824: ~ 2.1 GB real
In trunk, the additionally used memory is immediately released on zooming out again, however - depending on the complexity of the drawing, and the number of objects using such pattern fills - the latest increase of that additional memory usage [2] can render Inkscape trunk unusable for further editing such files on systems with lower amounts of RAM (e.g. a PC with 3GB and Ubuntu 13.10 installed, as used by the original reporter (on irc)): due to heavy swapping as soon as one attempts to zoom in closer, the whole system is brought close to a stand-still (aka hangs).
[1] Note: my tests on Ubuntu 13.10 in a VM (64bit) didn't allow to fully reproduce the test case: if zooming in to the selection, the pattern-filled object rendered as black rectangle with the size of its bounding box (no increase of mem usage for that). Zooming out to a level where the object was rendered correctly also triggered a spike in memory usage, but not as high as when zoomed in to selection. Testing with a slightly more complex sample document immediately locked the system temporarily (due to heavy swapping).
[2] AFAICT based on tests with archived builds, the recent increase of the amount of additional memory used is caused by the increase of the resolution of the pattern tile internally, changed in revision 12824 to address lower rendering quality reported in bug #1251039:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12824>
<https://bugs.launchpad.net/inkscape/+bug/1251039> |
Compared to current stable, the new cairo-based renderer seems to have always had a much higher memory usage when zooming in closely on objects with a pattern fill based on a large embedded bitmap image. Lately however, the memory usage when zooming in closely seems to have nearly tripled.
Steps to reproduce [1]:
1) launch current trunk with default (new) prefs
2) open the attached file
3) open a system utility which allows to monitor memory usage
4) select the only path in the file
5) zoom to selection '3'
--> memory usage "explodes"
6) zoom to page '5'
--> memory usage immediately reverts to prior level
Sample data (same steps with minimal test case, OS X 10.7.5, 8 GB RAM):
0.48.x r10015: ~ 170 MB real
0.48+devel rev <= 12823: ~ 760 MB real
0.48+devel rev >= 12824: ~ 2.1 GB real
In trunk, the additionally used memory is immediately released on zooming out again, however - depending on the complexity of the drawing, and the number of objects using such pattern fills - the latest increase of that additional memory usage [2] can render Inkscape trunk unusable for further editing such files on systems with lower amounts of RAM (e.g. a PC with 3GB and Ubuntu 13.10 installed, as used by the original reporter (on irc)): due to heavy swapping as soon as one attempts to zoom in closer, the whole system is brought close to a stand-still (aka hangs).
System & version info:
Reproduced with Inkscape 0.48+devel r13149 on OS X 10.7.5, with cairo 1.12.2, 1.12.16+downscale patch and cairo master (@ ed175b2)
=====
[1] Note: my tests on Ubuntu 13.10 in a VM (64bit) didn't allow to fully reproduce the test case: if zooming in to the selection, the pattern-filled object rendered as black rectangle with the size of its bounding box (no increase of mem usage for that). Zooming out to a level where the object was rendered correctly also triggered a spike in memory usage, but not as high as when zoomed in to selection. Testing with a slightly more complex sample document immediately locked the system temporarily (due to heavy swapping).
[2] AFAICT based on tests with archived builds, the recent increase of the amount of additional memory used is caused by the increase of the resolution of the pattern tile internally, changed in revision 12824 to address lower rendering quality reported in bug #1251039:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12824>
<https://bugs.launchpad.net/inkscape/+bug/1251039> |
|
