GNU bug report logs - #23431
Displaying animated GIFs can make Emacs unresponsive

Previous Next

Package: emacs;

Reported by: Juliusz Chroboczek <jch <at> pps.univ-paris-diderot.fr>

Date: Tue, 3 May 2016 03:31:01 UTC

Severity: normal

Found in version 25.0.93

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 23431 <at> debbugs.gnu.org, rgm <at> gnu.org, jch <at> pps.univ-paris-diderot.fr
Subject: bug#23431: 25.0.93; EWW hangs
Date: Tue, 03 May 2016 22:31:15 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Tue, 03 May 2016 21:05:21 +0200
> Cc: 23431 <at> debbugs.gnu.org, Juliusz Chroboczek <jch <at> pps.univ-paris-diderot.fr>
> 
> > It's 2036x1426, but is resized to never be more than ~ 1/4 of that size
> > even in a full-screen Firefox. So I don't think that gif by itself is
> > too indicative.
> 
> Yeah, it's an extreme GIF, but Emacs shouldn't become (almost) unusable
> in the presence of such images...  I mean, you have to kill the eww
> buffer to get anything done.
> 
> You can get pretty much the same effect by visiting a page that contains
> a number of smaller animated images.  

I've now run a longer profile, with image.el loaded (not .elc), and
the profile is this:

  - timer-event-handler                                            2905  90%
   - apply                                                         2905  90%
    - image-animate-timeout                                        2858  88%
     - if                                                          2858  88%
      - progn                                                      2858  88%
       - let*                                                      2858  88%
	- image-multi-frame-p                                      2858  88%
	 - if                                                      2858  88%
	  - progn                                                  2858  88%
	     let*                                                  2858  88%
    + url-queue-run-queue                                            47   1%

IOW, it insists that the problem is in the call to image-metadata.
Which probably mean most of the time is spent in lookup_image?

Can you run Emacs under prof to see what happens on the C level?

Btw, if I wait for a while (maybe 20 sec), the slowness disappears,
and Emacs becomes responsive again, although the animation still goes
on.  So perhaps what causes this is some initial processing?  (I have
no idea what's involved in displaying an animated GIF.)




This bug report was last modified 9 years and 69 days ago.

Previous Next


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