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: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.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 20:48:47 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> The timer set up by image.el keeps "displaying" the animated GIF.

Yup.  But if the image isn't displayed, why does this take any time?
That is, the image.el code increases the :index in the image spec, and
then calls force-window-update, and it's presumably this that takes
time?  Even if the image isn't displayed?  I find that part rather
unexpected.

Hm...  No, even without the force-update, Emacs uses 100% CPU.  I've
done some more testing, and even if image-animate-timeout just does:

  (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.

I guess 1) is because the redisplay code can't find the image in the
image cache -- because it has no concept of "this is an image-relevant
plist item" -- it just computes a hash of all the properties.

> 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.

>   . 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.

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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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