GNU bug report logs - #47895
28.0.50; Emacs should only animate images that are visible

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 47895 <at> debbugs.gnu.org
Subject: bug#47895: 28.0.50; Emacs should only animate images that are visible
Date: Sun, 25 Apr 2021 22:01:28 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 47895 <at> debbugs.gnu.org
> Date: Sun, 25 Apr 2021 20:48:47 +0200
> 
> Hm...  No, even without the force-update, Emacs uses 100% CPU.

Beware: changing that might make the timer run more frequently, so you
might see CPU usage soar even though Emacs does almost nothing.

>   (plist-put (cdr image) :animate-tardiness
>              (+ (* (plist-get (cdr image) :animate-tardiness) 0.9)
>                 (float-time (time-since target-time))))
> 
> and then re-runs itself, it'll use 100% CPU.  This seems to indicate
> that any alteration of the image plist leads to Emacs re-computing the
> image -- even if it isn't displayed?  Both of these things seem
> unexpected: 1) Altering a plist item that's not relevant for the display of
> the image shouldn't lead to an image recomputation, and 2) if the image
> isn't displayed, it shouldn't be recomputed anyway.

We access a different frame of the GIF image, so that would mean
regenerating the pixmap for the image, no?

> > In this simple case, we could use
> >
> >  (get-buffer-window (plist-get (cdr image) :animate-buffer) 'visible)
> >
> > in image-animate-timeout to see if the buffer is displayed in any
> > window.  The harder questions are:
> >
> >   . if the buffer is not displayed, what to do with the timer?
> >     continue running it? if so, how to interpret the LIMIT arg?
> 
> I'd keep interpreting that the same -- that is, count down, even if the
> image isn't displayed.

But then if and when the image becomes visible, it won't show the
animation, because it already reached the LIMIT.  Right?

> >   . what if the window _is_ displayed, but the image is not visible?
> >     I think we'd need to record the image's buffer position in its
> >     plist, so that we could use pos-visible-in-window-p to find out
> >     whether the image is visible
> 
> Or just compute the position on each iteration -- the image may change
> its position if more text is inserted, for instance.

Sure, but even if the position doesn't change we currently cannot tell
if the image is visible.  We have pos-visible-in-window-p, but that
needs a buffer position -- which is why I suggest to record that
position in the image.

> But I'm still wondering about why this doesn't just work
> "automatically" -- if we could handle this in the redisplay code, that
> would be more natural.

Animation doesn't work in redisplay, it works in this code I pointed
to.

Previous Next

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