trunk: huge spikes of memory usage when zooming in closely on objects with bitmap pattern fill

[su_v]

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>

[su_v (suv-lp)]

Attaching a small exported area of the (much larger) original image on which this report is based, to illustrate the context in which such kind of bitmap pattern are used.

[Tavmjong Bah (tavmjong-free)]

You can't have your cake an eat it too...

One solution would be to provide a user settable pattern resolution factor.

Any solution that solves both the image quality problem and this problem is not going to be simple.

[Krzysztof Kosinski (tweenk)]

This happens because we are being a little lazy. The current approach to pattern rendering is to calculate the size of the pattern tile based on the size of the pattern on the screen and render it to an image surface. However, if the tile is very large and based on e.g. an upscaled bitmap, we end up allocating a giant image for no reason and filling it with lots of interpolated data.

The fix would be to have a limit on the size of the allocated tile, e.g. 5MB. If this threshold is exceeded, we should switch to a different rendering strategy. Instead of rendering the entire tile to an image surface, we should just repeatedly draw it on the target surface inside a group. This group should then be composited using a mask based on the object's fill / stroke area. Unfortunately, this might cause some problems with seams at the edges of the tile.

[Vladimir Savic (vladimir-firefly-savic)]

How big is amount of work needed for this to be set straight? I was hit by same bug again today.

[Olof Bjarnason (objarni)]

I think this is related to this: https://bugs.launchpad.net/inkscape/+bug/1489168

[Olof Bjarnason (objarni)]

Reading Krzysztof Kosinski (tweenk)'s comment above, and browsing sp-patter.cpp around 620 I think I understand better what is happening now (in trunk, rev. 14334). The variable pattern_surface of type DrawingSurface is allocated to be of a HUGE size when zoomed in, which sounds ridiculous when thinking of what is happening; the used part of the tile is smaller and smaller the more you zoom in.

The size of the pattern_surface, which is just a mini rendering of the pattern onto a temporary bitmap, should not ever exceed the size of the viewport of the current window. So, a proposed fix for this would be to limit the resolution of the tile bitmap to the size of the viewport.

(The following comments what was gave me this idea:

    // Oversample the pattern
    // TODO: find optimum value
    // TODO: this is lame. instead of using descrim(), we should extract
    // the scaling component from the complete matrix and use it
    // to find the optimum tile size for rendering
    // c is number of pixels in buffer x and y.
    // Scale factor of 1.1 is too small... see bug #1251039
)

[Jonathan Hofinger (jhofinger)]

Hi - thanks for reporting this bug, I've manually migrated it to Inkscape's new bug tracker on GitLab, and closed it here.

Please feel free to file new bugs about the issues you're seeing at http://inkscape.org/report.

Moved to: https://gitlab.com/inkscape/inbox/issues/1778
Closed by: https://gitlab.com/jhofinger