bug#40685: 28.0.50; eww browser chews up 100% cpu when displaying looping gif animations
When opening a web page in the Emacs browser that contains infinite looping gif animations Emacs starts spinning up 100% CPU even after the emacs browser is closed. Emacs has to be completely shut down to reduce the CPU usuage.
If the 100% CPU process is allowed to run its course, it eventually stops after several minutes with the message, "Stopping animation; animation possibly too big".
In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.13, cairo version 1.16.0)
of 2020-04-16 built on localhost.localdomain
Repository revision: d5a7df8c02f04102d50a5cd2290262f59f2b1415
Repository branch: master
Windowing system distributor 'Fedora Project', version 11.0.12006000
System Description: Fedora 31 (Thirty One)
ad-handle-definition: ‘vc-revert’ got redefined
BBDB: sendmail insinuation deprecated. Use mail.
Cleaning up the recentf list...done (0 removed)
Turning on magit-auto-revert-mode...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Package cl is deprecated
Contacting host: bridgesense.com:443
ad-handle-definition: ‘open-network-stream’ got redefined
value of $LANG: en_US.UTF-8
Major mode: Dashboard
Minor modes in effect:
> When opening a web page in the Emacs browser that contains infinite looping gif animations Emacs starts spinning up 100% CPU even after the emacs browser is closed. Emacs has to be completely shut down to reduce the CPU usuage.
> If the 100% CPU process is allowed to run its course, it eventually stops after several minutes with the message, "Stopping animation; animation possibly too big".
Yeah, that triggers when it's taken more than two seconds to get the
next frame. Emacs can be totally unusable for a long time, though,
because we may get a new frame faster than that, but leave no CPU for
the rest of Emacs.
Lowering the limit seems like an obvious solution, but that will make
many animations stop if Emacs is occasionally busy with something else.
So that simplistic test is error-prone and doesn't really help that much
with the problem.
I wonder whether a different heuristic could be written... not
something that stops the animation if a single frame arrives too late,
but averaged over several frames. That is, if frames consistently
arrive (way) too late, then it's probably using all the CPU, and should
stop. Hm... it doesn't seem to hard two write something like that, I
think? I'll give it a go.