AW: Re: Free images based on allocated memory

AW: Re: Free images based on allocated memory

[Andreas Politz]

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

Yes, I know about image eviction delay.  Also, I'm not really sure if what I was proposing is a good idea.

One goal in my package is it to display PDF pages quickly. 
There are 2 factors delaying this:  The actual rendering in the back-end (via poppler) and the loading of the image by Emacs.  

In order to limit this timespan, pages are speculative pre-rendered and pre-loaded. E.g. if page n is currently displayed, the user probably wants to view page n+1 next. This is implemented by filling  a LRU cache while Emacs is idle.

Note how this conflicts with a least-recently-displayed eviction strategy.

Of course this can be solved in Lisp, just not very elegantly.  I spare you the details.

Another extension point, which would help managing the image-cache in my case, would be the ability to flush images based on their data.  Note, this is currenly only supported for file based images.

Thanks for taking the time,
Andreas

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

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

[Eli Zaretskii]

> Date: Thu, 31 Jan 2019 18:33:28 +0100
> From: Andreas Politz <politza@hochschule-trier.de>
> Cc: emacs-devel@gnu.org
> 
> Yes, I know about image eviction delay.  Also, I'm not really sure if what I was proposing is a good idea.
> 
> One goal in my package is it to display PDF pages quickly. 
> There are 2 factors delaying this:  The actual rendering in the back-end (via poppler) and the loading of the
> image by Emacs.  
> 
> In order to limit this timespan, pages are speculative pre-rendered and pre-loaded. E.g. if page n is currently
> displayed, the user probably wants to view page n+1 next. This is implemented by filling  a LRU cache while
> Emacs is idle.
> 
> Note how this conflicts with a least-recently-displayed eviction strategy.
> 
> Of course this can be solved in Lisp, just not very elegantly.  I spare you the details.

Thanks for the explanations, but I'm not sure I understand: is the
patch you proposed intended to fix these issues?  If so, can elaborate
on how it fixes them?

> Another extension point, which would help managing the image-cache in my case, would be the ability to flush
> images based on their data.  Note, this is currenly only supported for file based images.

Doesn't image-flush fit this bill?  If not, can you tell why not?