GNU bug report logs - #74537
[PATCH] An on-disk image modification does a cache miss

Previous Next

Full log

Message #11 received at 74537 <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74537 <at> debbugs.gnu.org
Subject: Re: bug#74537: [PATCH] An on-disk image modification does a cache miss
Date: Tue, 26 Nov 2024 19:38:35 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> 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 <at> 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.

Ok.

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

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

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.

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.

It seems I also lack some imagination about how users could use images
in Emacs.  For instance, with your example about alignment, I imagined
that it could be something that a user would do in its modeline (for
example) but with images that would never ever change.
-- 
Manuel Giraud

Previous Next

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