From: Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, 68006@debbugs.gnu.org
Subject: bug#68006: 30.0.50; Image-mode speed
Date: Mon, 01 Jan 2024 11:10:33 +0100 [thread overview]
Message-ID: <87v88d9xeu.fsf@ledu-giraud.fr> (raw)
In-Reply-To: <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@mail.gmail.com> (Stefan Kangas's message of "Sat, 30 Dec 2023 15:57:28 -0800")
Stefan Kangas <stefankangas@gmail.com> writes:
> Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs@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
prev parent reply other threads:[~2024-01-01 10:10 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-24 16:44 bug#68006: 30.0.50; Image-mode speed Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-24 17:01 ` Eli Zaretskii
2023-12-25 10:34 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-25 13:36 ` Eli Zaretskii
2023-12-25 18:59 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-25 19:30 ` Eli Zaretskii
2023-12-26 14:45 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-26 17:15 ` Eli Zaretskii
2023-12-26 18:07 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-26 18:43 ` Eli Zaretskii
2023-12-27 12:13 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-27 13:36 ` Eli Zaretskii
2023-12-29 11:11 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-29 12:13 ` Eli Zaretskii
2023-12-30 11:36 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-30 12:37 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-30 23:57 ` Stefan Kangas
2023-12-31 7:16 ` Eli Zaretskii
2024-01-02 0:19 ` Stefan Kangas
2024-01-02 12:10 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-02 12:49 ` Eli Zaretskii
2024-01-02 16:04 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-02 17:02 ` Eli Zaretskii
2024-01-04 16:47 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-04 17:43 ` Eli Zaretskii
2024-01-04 18:42 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-04 18:55 ` Eli Zaretskii
2024-01-04 19:16 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-04 19:54 ` Eli Zaretskii
2024-01-05 10:50 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-05 11:25 ` Eli Zaretskii
2024-01-05 13:26 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-05 13:40 ` Eli Zaretskii
2024-01-05 14:35 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-05 14:41 ` Eli Zaretskii
2024-01-05 14:54 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-06 13:07 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-01 10:10 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v88d9xeu.fsf@ledu-giraud.fr \
--to=bug-gnu-emacs@gnu.org \
--cc=68006@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=manuel@ledu-giraud.fr \
--cc=stefankangas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).