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.

dupe of bug 86319 (large animated GIF has terrible performance) see also bug 94828 *** This bug has been marked as a duplicate of 86319 ***

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)

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

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

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

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

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

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.

Tor should be in on this fun with GTK & anims

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

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?

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

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

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%)

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.

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

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

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.

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

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

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!

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.

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!

Shouldn't this block bug 595574?

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?

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