bug#47895: 28.0.50; Emacs should only animate images that are visible

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 47895@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.