bug#68006: 30.0.50; Image-mode speed

[Stefan Kangas <stefankangas@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Sat, 30 Dec 2023 15:57:28 -0800
>> Cc: 68006@debbugs.gnu.org
>>
>> Taking a step back, why are images treated differently from other
>> buffers?  If the risk is that the image changes on disk without us
>> noticing, then users should need to either run `revert-buffer' or enable
>> `auto-revert-mode'.  If we are talking about images that are inline in a
>> buffer, the cache should be flushed only when the buffer itself is
>> reverted.  What am I missing?
>
> See my explanation of the purpose of this particular cache here:
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68006#14

I read that, yes.  Quoting what you wrote there, and I hope I'm quoting
the most relevant part:

    > The real purpose of the image cache is not to hold the image in
    > memory for displaying it again and again, the purpose is to allow
    > the display engine to generate the pixels once, then reuse those
    > pixels during the current redisplay cycle or a few following
    > redisplay cycles.

Basically, I don't see how this difference relates to manually evicting
the cache or not.

> In a nutshell, this cache is ephemeral anyway, and will be flushed at
> some arbitrary time whether we want it or not, because its purpose is
> not what you think it is.

If it is flushed anyways, then that is exactly what we want here, I
think.  The idea is to flush it less often, AFAIU.

> In any case, if you intend to not flush the cache at all, then what
> does that mean for Emacs sessions running for days and weeks, let
> alone months, on end? will they keep these images in memory forever?
> Or should GC sometimes evict those images from the cache, and if so,
> under what conditions?

Are you saying that, if this particular call is removed, we will never
flush the cache (i.e. we will have memory leaks)?