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: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 68006 <at> debbugs.gnu.org
Subject: bug#68006: 30.0.50; Image-mode speed
Date: Mon, 01 Jan 2024 11:10:33 +0100

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs <at> gnu.org> writes:
>
>> And here is a new version of the patch.  Maybe, we need a NEWS entry for
>> this too.
>
> If we have an option, then yes we should add it to NEWS too.
>
> But I'm not sure about this one:
>
> Flushing the image cache all the time is fine for images that are 4KB in
> size, but these days we routinely work with images that are several
> megabytes in size (to give an idea, searching online tells me that
> Twitter allows uploading photos up to 2 MB, Facebook up to 15 MB).

Hi Stefan,

First, I want to say that here we're just talking about image-mode (and
its derivatives like docview) and how the image cache is managed in this
mode only.

"Flushing the image cache all the time" is what is done *now* in
image-mode.  In fact, this new option permits to inhibit it.

> Furthermore, my experience with image-dired has taught me that Emacs is
> terribly slow when compared to all other programs capable of viewing
> images out there.  So I think we should think a bit more about this
> one.

Yes and this slowness was what I wanted to speed up in the first place
in image-mode: moving from one image to the next is slower than any
other program.  I know that working on the image cache is picking a
low-hanging fruit here but I'm not an expert in fast image processing.

> 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?

I guess that makes sense but would it be easy to plug the
'revert-buffer' machinery into the image cache internals?  I don't know.

> Lastly, I'm not sure about the "hash the first 4 KB of an image"
> heuristic, for starters because images can be several megabytes in size.
> Would it not be both more accurate and faster to check the mtime and/or
> the size of the file?  Or do we need different heuristic for different
> image formats?  (Maybe JPEG changes the first 4 KB on save, but I don't
> think all bitmap formats do.)  But wouldn't it be even better to use the
> notify system when possible, like with `auto-revert-use-notify'?

You're right that this heuristic might not be the best one.  I
repurposed it from image-dired when Eli suggested something content
based.  Maybe we could have a modification time of the image into its
spec and compare it to said image file before display.

Best regards,
-- 
Manuel Giraud

Previous Next

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