Memory leak when zooming big file

- not reproduced on Windows 7, 32 bit, Inkscape 0.91 r13725 (Jan 30 2015)
   the response is admittedly slow, but not unexpectedly so, and zooming in to 25600% does not seem to make it worse.
- similar behavior on Windows XP, recent 32 bit trunk build of Inkscape.
- unfortunately I no longer have 0.48.4 available for testing.

attached is a screenshot of memory usage on Windows 7. The memory initially maxes out at 2GB, which is all there is. Then it stabilizes back to about 1.2GB and bahaves well after that. The spikes are periods where I was zooming in.

I can see the problem on this Ubuntu 14.10 computer. It's an older hardware with 3GiB of RAM. Beyond some zoom level I see a lot of swapping happening. Haven't bothered to measure exact numbers, but system does become unresponsive. Could this be related to bug #1292459 ?

As described (excessive increased memory usage on close zooming in):
- not reproduced with Inskcape 0.58.5 r10040
- reproduced with Inkscape 0.91 r13725 and 0.91+devel r13935
on OS X 10.7.5. Inkscape 0.91+devel builds had been tested with cairo 1.12.2, 1.14.0 and recent git master (same results).

The file is also affected by
- Bug #1198317 “Dragging objects in compex document very slow in 0...”
  https://bugs.launchpad.net/inkscape/+bug/1198317

On 2015-02-21 16:23 (+0100), Vladimir Savic wrote:
> (...) Could this be related to bug #1292459 ?

Unlikely the same underlying issue - there are no pattern fills used in the sample file from comment #1. The only similarity I notice is that memory usage is immedtiately reverting to prior levels when zooming out (not a mem leak?).

Correction (Typo in version number)
- - not reproduced with Inskcape 0.58.5 r10040
+ - not reproduced with Inkscape 0.48.5 r10040

I'm experiencing the same problem with Inkscape 0.91 in Ubuntu 15.04. When I open the .svg image linked above, the resident set size of Inkscape is initially about 140MB, but as I zoom in this balloons to over 6GB, I hit the swap, and my system grinds to a halt.

I'm having lots of trouble getting Inkscape 0.48.5 to compile on Ubuntu 15.04, so at the moment I can't confirm whether or not this is a regression.

Retesting (since this report came up recently on irc too) with archived and latest trunk builds (on OS X 10.7.5):
- reproduced with rev <= 13964,
- not reproduced with rev >= 13968;
it seems this regression was fixed with the changes in r13966:
* Fix out-of-control render cache from dominating all available memory
  http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13966

@Liam - any caveats to be considered wrt backporting to 0.91.x?

trunk r13966 backported in 0.91.x r13772

I retested too (ubuntu 14.04.2 amd64) :
- reproduced with rev 13965
- not reproduced with rev 13966

The commit "Fix out-of-control render cache from dominating all available memory" by Liam seems to fix this.

Thanks :-)