AW: Re: AW: Re: Free images based on allocated memory

AW: Re: AW: Re: Free images based on allocated memory

[Andreas Politz]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

The patch limits the amount of memory Emacs may use for an image-cache.  This if what my users want and it means I don't have to implement it in Lisp.  So, given the cache has still vacancy left, I can preload not yet displayed images into it knowing they stay there.  Using the existing time-based mechanism doesn't really work here:  Either  the limit is to short and thus pre-loaded images are evicted before they can be displayed. Or it is to long and the image-cache becomes undesirable large.

---

I use data-strings as basis for the image-descriptor, rather than files.  In some scenarios multiple descriptor share their image-data. Since images can't be flushed based on the data property (as opposed to the file one), I would have to keep track of these dependencies between descriptor and data, since my own cache stores these data strings and not the actual images.

Andreas


[-- Attachment #2: Type: text/html, Size: 1110 bytes --]

Re: AW: Re: AW: Re: Free images based on allocated memory

[Eli Zaretskii]

> Date: Mon, 04 Feb 2019 17:42:32 +0100
> From: Andreas Politz <politza@hochschule-trier.de>
> Cc: emacs-devel@gnu.org
> 
> The patch limits the amount of memory Emacs may use for an image-cache.  This if what my users want and
> it means I don't have to implement it in Lisp.  So, given the cache has still vacancy left, I can preload not yet
> displayed images into it knowing they stay there.  Using the existing time-based mechanism doesn't really
> work here:  Either  the limit is to short and thus pre-loaded images are evicted before they can be displayed.
> Or it is to long and the image-cache becomes undesirable large.

Did you try this code when there's only one or two large images being
displayed in some window, such that each one of the images
individually exceeds the memory limit set by the variable your patch
introduces?  Doesn't this cause Emacs to constantly free and then
immediately re-process the image again and store it in the cache,
e.g., as you scroll the window to bring the image in and out of view?

Please also note that I installed a change today that prevents a
frame's image cache from being altered while the display engine works
on that frame.  This caused Emacs to segfault in some convoluted
situation.

Thanks.