unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Francis Meetze <francis@bridgesense.com>
Cc: 40685@debbugs.gnu.org
Subject: bug#40685: 28.0.50; eww browser chews up 100% cpu when displaying looping gif animations
Date: Wed, 29 Jul 2020 08:24:24 +0200	[thread overview]
Message-ID: <87v9i62607.fsf@gnus.org> (raw)
In-Reply-To: <87zhbagh46.fsf@localhost.localdomain.i-did-not-set--mail-host-address--so-tickle-me> (Francis Meetze's message of "Fri, 17 Apr 2020 10:24:41 -0700")

Francis Meetze <francis@bridgesense.com> writes:

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

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





  reply	other threads:[~2020-07-29  6:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-17 17:24 bug#40685: 28.0.50; eww browser chews up 100% cpu when displaying looping gif animations Francis Meetze
2020-07-29  6:24 ` Lars Ingebrigtsen [this message]
2020-07-29  6:39   ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v9i62607.fsf@gnus.org \
    --to=larsi@gnus.org \
    --cc=40685@debbugs.gnu.org \
    --cc=francis@bridgesense.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).