From: Eli Zaretskii <eliz@gnu.org>
To: Manuel Giraud <manuel@ledu-giraud.fr>
Cc: 74537@debbugs.gnu.org
Subject: bug#74537: [PATCH] An on-disk image modification does a cache miss
Date: Tue, 26 Nov 2024 15:31:50 +0200 [thread overview]
Message-ID: <86plmiglyx.fsf@gnu.org> (raw)
In-Reply-To: <87ed2z6m7q.fsf@ledu-giraud.fr> (bug-gnu-emacs@gnu.org)
> Date: Mon, 25 Nov 2024 22:24:25 +0100
> From: Manuel Giraud via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> With this patch, when an image file is modified on disk, the associated
> cache image is invalidated and re-read from disk.
Thanks, but I'm not sure it's a good idea to do that automatically
whenever lookup_image is called.
First, lookup_image is called only when we need to create or access an
image with only its Lisp descriptor in hand; once the image has been
displayed, that should happen relatively rarely. For example, the
glyph matrices used to manipulate the display record only the image's
cached ID, and the code accesses the cached image without calling
lookup_image. So this change could have weird confusing effects,
whereby the fact that the image was modified on disk becomes apparent
only after some display-related actions, but not after others. For
example, scrolling a window by a small amount will not notice the
change on disk, whereas significant changes, especially when the image
goes off the window and back into it, will show the change. Don't you
see such issues if you install the change?
Second, if the image is already on display, and the file changes on
disk, some layout calculations could see different dimensions than
what is actually on display, which will cause subtle bugs. For
example, what if there's a 'display' property such as this:
'(space :width (0.5 (image PROPS)))
and an image with those same PROPS is already shown on display? The
code which implements the above calls lookup_image, which will
simulate a cache miss if the file has changed, and will then load the
new file, which could return dimensions different from the image
already on display. So the width of the space glyph produced by the
above will be different from that of the displayed image, and we could
have misalignment until the next redisplay which redraws the image.
So I think this should probably be controlled by a variable visible
from Lisp, by default off, and we might also have a function to
invalidate all the cached images whose files have changed (which will
then need to trigger a thorough redisplay, I think).
next prev parent reply other threads:[~2024-11-26 13:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-25 21:24 bug#74537: [PATCH] An on-disk image modification does a cache miss Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-26 13:31 ` Eli Zaretskii [this message]
2024-11-26 18:38 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-27 14:17 ` Eli Zaretskii
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=86plmiglyx.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=74537@debbugs.gnu.org \
--cc=manuel@ledu-giraud.fr \
/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).