GNU bug report logs - #61763
30.0.50; Image Cache Size growth

Previous Next

Full log

View this message in rfc822 format

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61763 <at> debbugs.gnu.org
Subject: bug#61763: 30.0.50; Image Cache Size growth
Date: Fri, 24 Feb 2023 22:32:49 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

[...]

> JPEG compression is very good, it routinely compresses images with
> ratios of 10:1 to 20:1.  If I use djpeg to convert the 2 MiB images I
> used into BMP, I get 36 MiB BMP files -- that's a 1:18 expansion
> ratio.  And Emacs converts each image to a pixmap for display, which
> is basically similar to what I did.  Multiply that by 20 or 30, and
> you get the numbers you see, I think.

Yes, one of the images I'm using is 3264 by 2448 pixels times 3 octets
(RGB, I guess) and we get about 23MiB... so those numbers seems ok.

> The solution is to enlarge the VM for your machine (by enlarging swap,
> for example).  If you don't keep those images displayed in windows,
> lowering image-cache-eviction-delay might also help.

In image.c line 2079, there is already a mecanism to automatically lower
this delay if the cache has grown large (so I think we're covered here).

But OTOH, at line 3010, we can see that this cache will grow no matter
what.  Maybe we should have parameter (maybe a custom) that limit this
growth up to a certain point and then start uncaching older images.
WDYT?
-- 
Manuel Giraud

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.