[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#47895: 28.0.50; Emacs should only animate images that are visible
From: |
Eli Zaretskii |
Subject: |
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@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.
- bug#47895: 28.0.50; Emacs should only animate images that are visible,
Eli Zaretskii <=