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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 68006 <at> debbugs.gnu.org
Subject: bug#68006: 30.0.50; Image-mode speed
Date: Tue, 26 Dec 2023 19:15:46 +0200

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: 68006 <at> debbugs.gnu.org
> Date: Tue, 26 Dec 2023 15:45:11 +0100
> 
> >> About being sure to display the file on disk, maybe we could call
> >> 'image-flush' only if the file has changed since its display.  WDYT?
> >
> > Provided that the check is reliable, I guess so.
> >
> > In any case, I think we should be cautious and leave a knob to get
> > back the old behavior, in case there are some situations we don't
> > anticipate that need to flush the caches.
> 
> Hi,
> 
> What do you think of this?  Of course, it will need a NEWS entry but I
> wanted to polish it first.  I have made it opt-in.  I have used it a bit
> the cache could grow fast but I find it quite pleasant to use (for
> Docview also).

Using img->timestamp is not reliable enough, since that timestamp is
updated each time we call prepare_image_for_display, which can happen
many times during a session for the same image, and not necessarily
for actually displaying the image in a window.  For example, AFAICT if
you move across an image with C-n/C-p, we update the time stamp each
time vertical motion crosses the screen line with the image.  So I
think we'd need to store the file's time stamp or some other
signature.

The comparison with times-less-p is also risky: what if someone
replaces the image file with an older file?

I'd trust some kind of file checksum better, which we will have to
store alongside the image spec or as part of it.  (Don't we already do
something like that somewhere in image-*.el files?)

Previous Next

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