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

Previous Next

Full log

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

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

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 47895 <at> debbugs.gnu.org
> Date: Sun, 25 Apr 2021 21:07:48 +0200
> 
> > We access a different frame of the GIF image, so that would mean
> > regenerating the pixmap for the image, no?
> 
> It does, but why does that happen before redisplay has decided to
> display the image?

Because image-animate-timeout calls image-metadata (via
image-multi-frame-p), which calls lookup_image, which regenerates the
pixmap.

> >> 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?
> 
> Yes.  I think that's fine -- you've asked for X repetitions, and you get
> X repetitions, whether it's shown or not.

But no repetitions were actually displayed yet, so won't this be
confusing?  Shouldn't we start counting only when the image is
actually visible?

> > Animation doesn't work in redisplay, it works in this code I pointed
> > to.
> 
> The code just alters some elements in the image plist.  It's unexpected
> that this should lead to Emacs doing a lot of work -- unless it's
> actually displaying the image.

It's computing the image, see above.

Previous Next

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