120154 - animated GIF eating cpu when mozilla in another tab or minimized

Status: RESOLVED DUPLICATE of bug 666446

(Core :: Graphics: ImageLib, defect)

Description

[Jeremy M. Dolan]

On tinderbox right now, one machine is flaming. One table cell has the animated
bg image of the fire.

Sitting on the page, looking at the image: 32% CPU
Scroll below/above it: 0% CPU (good)
looking at the image, then switch to another tab: 10% CPU. (falls for some reason,
                                                            but should be 0)
looking at the image, then minimize Mozilla: 32% CPU (no change, should be 0)

URL is a CPU intensive GIF for testing with.

Comment 1

[Matthias Versen [:Matti]]

dupe of bug 86319 (large animated GIF has terrible performance)
see also bug 94828

*** This bug has been marked as a duplicate of 86319 ***

Comment 2

[Alexey Zakhlestin]

seems to me, it's NOT a dupe.
Problem is not large CPU usage, but large CPU usage, when the gif is not visible
(except scrolled case)

Comment 3

[Jeremy M. Dolan]

Right. I linked to that gif just for testing purposes. Please read the
description more carefully, Matti. Reopening.

Comment 4

[basic]

we are painting the images even when it is not visible?

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Please recheck with a build including tonights checkin for bug 125025 (to
nsImageGTK.cpp).  Should be in tonight's nightly.  I suspect this will greatly
reduce cpu use (although the patch will not eliminate all CPU use when
minimized/etc).

Comment 6

[Jo Hermans]

*** Bug 106125 has been marked as a duplicate of this bug. ***

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

I'll attach a jprof.  This bug is not affected by the bug 125025 changes (since
it's not transparent).

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

Attachment: jprof of the URL for this bug, in a non-visible tab

This jprof (using a build from friday) shows that (as noted in bug 125025)
anims continue to animate when not visible.  Bug 125137 is relevant as well
(anims run faster than intended).

The correct solution is to not try to draw a non-visible anim.	Next best would
be to make the anim drawing code optimal, but unlike transparent anims, I don't
think there's a lot of room for optimizing.

Note that the CPU time is in memcpy (from FillWithColor, which has some hits of
 it's own, and DrawTo) and gdk_draw_rgb_image_core, which calls
gdk_rgb_convert_565_d and gdk_draw_image (which spends it's time in write()). 
Total for those is ~1800 out of ~2100 hits.

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

Tor should be in on this fun with GTK & anims

Comment 10

[Boris Zbarsky [:bzbarsky]]

*** Bug 129165 has been marked as a duplicate of this bug. ***

Comment 11

[ArronM (:paper)]

With the resolution of Bug 125137, the effects of this bug become less apparent.
 They still exist to the same extent as they did before, but since all the
examples were at 10ms frame delays, and are now being displayed at 100ms frame
delays, you don't see the CPU hit as much anymore.

Changing URL from:
http://www.livingingreytown.com/comics/grey20010919.gif

To a better example at:
http://animecity.nu/Mozilla/IMGTest/Bug120154.gif

This test should result in 1/2 the CPU usage when minimized/not visible (Tried
it on RC1 & 2002050705)

The problem is that ImageLib must continually compose the frames of the
animation, even when the image is not being displayed.  Sometimes composing
frames can take up to 50% of the "drawing" time.

Solutions?  
-We could stop animation while the image is not visible.  This may annoy people
who put the gif in the background for xx seconds because the cool part of the
animation isn't for another xx seconds.

-We could compose all the frames once and store them.  This may take up a huge
amount of memory, and ImageLib is horrible for memory consumption as it is.

-We could just increment the current frame # counter while the image is not
visible, and NOT composite.  When it becomes visible, we'd have to build the
compositing frame from the frame-since-we-became-invisible on to the
frame-we-became-visible on.  This will eat up CPU and take a lot of time on some
animations.


I don't like any of the solutions.  The first solution would be the biggest win
all around.

Could we get jprof for the new URL?

Comment 12

[Michael Lefevre]

*** Bug 124972 has been marked as a duplicate of this bug. ***

Comment 13

[ArronM (:paper)]

hmm, CPU while http://animecity.nu/Mozilla/IMGTest/Bug120154.gif is minimized is
at 1% on Build 2002100317, down from 22% on 1.0.

I'll see if I can find out which day we gained performance.
I'll be resolving this bug to FIXED in the next few days, unless someone's
seeing high CPU for the URL when minimized. :)

Comment 14

[Jeremy M. Dolan]

Linux 20021002, 100% CPU at that URL, and 88% when Mozilla is shaded or
iconized, or fliped to another tab. Sawfish 2.0 is the window manager. (The
version Red Hat 8.0 ships).

Maybe it's not sending Mozilla the iconification notice it expects?

I get similar figures for the original URL (87% -> 73%)

Comment 15

[ArronM (:paper)]

Ok, will leave bug open.  I would switch the OS to linux, but it's already
there. :P  
I'll still look into why CPU usage dropped to 1% on Windows.. might me something
there for linux to gain from.

Comment 16

[Adam D. Moss]

Just FYI, 33% cpu here when minimized, 34% when
not minimized.  (Linux.)

Comment 17

[franz]

On Windows 2000 SP2 and Mozilla Build 2002101612 I get ~97% with that latest
URL. When the window is minimized, CPU usage drops to ~7%.

Comment 18

[Randell Jesup [:jesup] (needinfo me)]

I suspect something in win32 is shortcutting when minimized.

BTW, solution #2 I've seen some systems (spyglass) use solution #2.  IE is more
interesting, it apparently composites each from from the starting one on each
frame draw.  With large, complex anims each frame will take more and more CPU to
draw until it finally hits the end-of-sequence, and then CPU use will drop back
to almost nil and start climbing again.

I think the best solution is #3, though it's also more complex.  Don't spend the
CPU until you need to.  Anims becoming visible is a not-too-frequent occurance,
and rarely will you have to composite a large number of frames (often none). 
You'll even get a speed advantage because of cache locality when doing the frame
1->current (or frame N->current) compositing.

Comment 19

[Erik]

*** Bug 204002 has been marked as a duplicate of this bug. ***

Comment 20

[Timothy Miller]

I'm using the latest nightly build (2009-2-14), and Firefox excessive CPU usage is still a problem.  A completely empty session (no windows open), and Firefox still uses at least 2% CPU.  What's it doing?  Right now, I have 13 tabs open, but there are no plugins, no flash, no animated gifs.  Firefox is using 10% CPU time.  (This is on a 2.33GHz Core 2 duo.)

Comment 21

[Richard Mlynarik]

Verified still present in Firefox 3.5.7 MacOS 10.6.2.

If a GIF isn't visible -- which includes being in an inactive tab, the is the test case I just verified -- then it shouldn't consume ANY CPU cycles.  Periodic display event timers simply shouldn't be firing, let alone performing any action.

Instead FF insists on doing its stupid Javascript GIF dance, periodically garbage collecting as a result, sometimes eating enough CPU that laptop fnas run, and evenetually draining down my laptop battery, all for *NO PURPOSE*.

I'd very much like to see this one dealt with.  It's only been eight years since it was reported!

Comment 22

[Timothy Miller]

There may be some good reasons to have Javascript do stuff in background tabs.  For instance, this is really important for my gmail account, especially if I have chat windows open.  That being said, I completely agree that GIFs shouldn't be animated.  Even if you have to pretend to animate it, I can't imagine how it could take a noticeable amount of CPU time just to increment a frame number.

I think that things Javascript and animations and especially Flash should seriously be throttled for CPU time when in completely hidden windows and tabs.  Some exceptions should be made for cases where two windows are both visible.  But for a completely inactive tab?  I don't know.  MAYBE if you've got a youtube video going and just want to listen to the audio.  Of course, we need to switch away from using Flash anyhow.

The thing that really bugs me is that FF uses CPU when it literally has nothing to do.  Some changes have been made in the past to make FF more event-driven, but apparently there's still a lot more to do.

Comment 23

[Richard Mlynarik]

PS I run noscript (and kill heinous Flash altogether) for good reason -- I don't like stupid/evil web sites consuming resources and performing actions on my machine behind my back.  So it's especially galling that Firefox itself decides it wants to busy wait running idle loop scripts and triggering frequent (for me) garbage collections!

0% CPU should be the standard for an idle application.  Three cheers for blocking in the poll() system call!

Comment 24

[[Baboo]]

Shouldn't this block bug 595574?

Comment 25

[Jon Hemming]

When browser is minimized shouldn't it use also API provided in bug 343515 to tell for topmost tab that it is not active anymore?

Comment 26

[Benoit Girard (:BenWa)]

Attachment: gif for testcase

Comment 27

[Benoit Girard (:BenWa)]

Attachment: Testcase

Comment 28

[Benoit Girard (:BenWa)]

CPU usage is significantly lower when minimized/background tab however not zero. Talked with Joe, this should be improved with changes to the nsRefreshDriver.