GNU bug report logs - #68006
30.0.50; Image-mode speed

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: stefankangas <at> gmail.com, 68006 <at> debbugs.gnu.org
Subject: bug#68006: 30.0.50; Image-mode speed
Date: Thu, 04 Jan 2024 20:16:19 +0100

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

>> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> Cc: stefankangas <at> gmail.com,  68006 <at> debbugs.gnu.org
>> Date: Thu, 04 Jan 2024 19:42:53 +0100
>> 
>> But anyway, you're thinking about another image cache completely user
>> manageable?
>
> Yes.
>
>> I guess it is a much more harder problem to tackle.
>
> Probably.  But anything else will be IMO a kludge.  (We do have
> kludges in Emacs, so we could have one here as well, of course.  I
> just thought that it would be good to avoid it if possible).

Ok.

>> For starters, as the current image-mode is using the 'image' display
>> property which uses the current image cache, I imagine that it
>> should then be replaced by something else?

Thinking about that, maybe we could have this other cache on top of the
current one (and still on top of the image display property).

> Yes, probably.  And if you are going for the simple solution, please
> keep in mind that image-cache-eviction-delay is a global variable, and
> the images are cached on a per-frame basis.  So if image-mode enlarges
> image-cache-eviction-delay, it will affect all the images, not just
> those in image-mode buffers.  One more reason why I think we should
> provide a separate and differently managed cache for this purpose.

Ok.  Maybe we should re-use the current C cache code with a "nice"
interface for this too.
-- 
Manuel Giraud

Previous Next

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