bug#59902: 30.0.50; Image overlay is not updated until the cursor moves to the overlay

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: 59902@debbugs.gnu.org
> Date: Sun, 11 Dec 2022 09:19:16 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The idea of clearing images from time to time was discussed, but AFAIR
> > we didn't find a good way that fits all the needs for doing so.
> 
> Are you referring to https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33275
> ?

That's one of them, yes.  There were others.

> I do not see anyone proposing cache expiry time there. Expiry is not
> really related to this particular bug report, but might be a good idea
> to help large memory consumption that is reported from time to time (I
> reported once for pdfs and I have seen people report memory issues with
> images).
> 
> > I think this is best left to the application level.  In particular, in
> > this case, the application _knows_ when it will replace the image
> > file.
> 
> No. Not really. Source block execution does not pass any information
> about updating/not updating images to Org image display code. Even if it
> did, the same issue could appear when the image file changes on disk
> outside Emacs.

Then I don't think I understand what you expect Emacs to do in these
cases.  We have no idea when the image file is replaced, and cannot
have such an idea without examining the file at high enough frequency.
Doing this "from time to time" is going to miss some changes, or take
note of them too late.  What else is possible?

> I was still able to make some improvements in Org's image code thanks to
> your replies.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a12d15df9
> 
> Yet, do note that flickering two different image versions when moving
> point is unexpected even considering the information you provided.

Flickering is expected when you do something that affects a large
portion of the Emacs display.  For example, the same will happen if
you change a large overlay at high enough frequency.  There's no way
around that except not doing that.

Why was this implementation chosen for whatever feature that produces
images?  Emacs doesn't react instantly to changes in disk files that
it visits, and here you expect it to do so.  Isn't it possible to
implement this in some other way, like have the program produce its
image data in a temporary Emacs buffer, then use that buffer's
contents for creating an image?  Then I believe the updated image will
have a different hash value, and there will be no cache-related
collisions.