GNU bug report logs -
#23431
Displaying animated GIFs can make Emacs unresponsive
Previous Next
Full log
View this message in rfc822 format
> 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.