[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, 25 Apr 2021 22:01:28 +0300 |
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 47895@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.
- bug#47895: 28.0.50; Emacs should only animate images that are visible, Lars Ingebrigtsen, 2021/04/19
- bug#47895: 28.0.50; Emacs should only animate images that are visible, Eli Zaretskii, 2021/04/19
- bug#47895: 28.0.50; Emacs should only animate images that are visible, Lars Ingebrigtsen, 2021/04/19
- bug#47895: 28.0.50; Emacs should only animate images that are visible, Eli Zaretskii, 2021/04/19
- bug#47895: 28.0.50; Emacs should only animate images that are visible, Eli Zaretskii, 2021/04/20
- bug#47895: 28.0.50; Emacs should only animate images that are visible, Lars Ingebrigtsen, 2021/04/25
- bug#47895: 28.0.50; Emacs should only animate images that are visible,
Eli Zaretskii <=
- bug#47895: 28.0.50; Emacs should only animate images that are visible, Lars Ingebrigtsen, 2021/04/25
- Message not available
- bug#47895: 28.0.50; Emacs should only animate images that are visible, Alan Third, 2021/04/27
- bug#47895: 28.0.50; Emacs should only animate images that are visible, Lars Ingebrigtsen, 2021/04/27