unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 74537@debbugs.gnu.org
Subject: bug#74537: [PATCH] An on-disk image modification does a cache miss
Date: Tue, 10 Dec 2024 17:42:56 +0100	[thread overview]
Message-ID: <87msh3h4kv.fsf@ledu-giraud.fr> (raw)
In-Reply-To: <86v7w8g3rb.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 27 Nov 2024 16:17:28 +0200")

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: 74537@debbugs.gnu.org
>> Date: Tue, 26 Nov 2024 19:38:35 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > 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?
>> 
>> I've tried a bit with image-mode and also with something like:
>> 
>> (insert (propertize "f" 'display '(image :file "/tmp/foo.jpg" :type jpeg :width 100)))
>> 
>> and, yes, I can see the behavior you describe.  But I also can't really
>> see why it is a problem: the image has changed!  At one point it should
>> be reflected in Emacs, no?
>
> First, that isn't always true.  Consider a file visited in some Emacs
> buffer -- we don't revert it automatically when the visited file on
> disk changes, do we?  We have commands and minor modes to do that, but
> they are optional.  Why should images be different?
>
> But yes, it would be good to have a mode and command(s) to update the
> images when/if they were modified.  We just must be sure we update
> _all_ of them, so if an image is displayed in several buffers/windows,
> the update affects all of them.  Otherwise we will have weird bugs
> like the one above.  And since the display engine has its own ideas
> for when to perform a thorough redisplay and when flush the image
> cache, these bugs will be hard to reproduce and debug.
>
> My point is that, since the display engine goes out of its way to try
> not to do stuff that isn't necessary, it will not "re-lookup_image" if
> it has no reason to believe what's on display is outdated.  The image
> cache is there to make redisplay of windows showing images faster.
> What you want here is to disable some of these optimizations under
> certain circumstances, but that must be done correctly, to avoid
> incorrect/inaccurate/confusing display.
>
>> This I've tried with:
>> 
>> (insert (propertize "foo" 'display '(space :width (0.1 . (image :file "/tmp/foo.jpg" :type jpeg)))))
>> 
>> and also the re-alignment occurs at /some/ point.  But likewise, I fail
>> to see why this is a problem.
>
> It is a problem because what the Lisp program which used such a
> property wanted (alignment on display) will not happen, since the
> image on display and the one you generate by calling lookup_image in
> the above scenario might have different metrics.  What we must somehow
> do in this case (assuming the user indeed wants the images to
> immediately reflect their disk file changes) is to update the image on
> display as well.  One way of doing that is to perform a complete
> redisplay of each window which shows the image.  I'm not sure, but it
> could be the only way, which means such updates will be somewhat
> expensive if one has many windows with the image.  (One trivial case
> where an image is displayed many times is the tool bar, when you have
> many frames.  Another case could be the mode line.)
>
>> After all, maybe I'm a bit partial to image-mode with this patch.  I
>> think my idea was to eventually get rid of the systematic `image-flush'
>> call in "image-mode.el" to make it beneficiate from the image cache more
>> and still be able to display the correct image.
>
> Sorry, I don't understand: the patch you posted effectively flushes
> the cache more often, so how is it more beneficial to users of the
> cache?

It flushes the cache iff the on-disk image has changed (which is, of
course, rare)... I think this all boils down to the fact that I don't
really understand the purpose of the `image-flush' call in image-mode.el
-- 
Manuel Giraud





      reply	other threads:[~2024-12-10 16:42 UTC|newest]

Thread overview: 5+ 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
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
2024-12-10 16:42       ` 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=87msh3h4kv.fsf@ledu-giraud.fr \
    --to=bug-gnu-emacs@gnu.org \
    --cc=74537@debbugs.gnu.org \
    --cc=eliz@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).