Animated images (GIFs) cause severe performance issues

RESOLVED FIXED

Status

()

Core
Graphics
--
major
RESOLVED FIXED
7 years ago
a year ago

People

(Reporter: Alex, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {perf, regression})

unspecified
x86
Windows XP
perf, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 .x+)

Details

(Whiteboard: [unscoped][softblocker])

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b6pre) Gecko/20100911 Firefox/4.0b6pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b6pre) Gecko/20100911 Firefox/4.0b6pre

This is a recent development. Animated GIF images make Firefox use a lot of CPU power, which causes Firefox to become sluggish. 

For example, on an Intel Atom N270, the animated smilies on the 'Post a Reply' page on mozillazine cause Firefox.exe to use ~49% CPU.

Reproducible: Always

Steps to Reproduce:
1. Open Firefox
2. Open a page with an animated GIF
Actual Results:  
Firefox uses a lot of CPU power to animate those things.

Expected Results:  
Firefox should remain mostly idle.

Reproducible without D2D and HW Layers.
Reproducible just with D2D.
Reproducible just with HW Layers.
Reproducible without any HW acceleration.

Comment 1

7 years ago
Created attachment 474550 [details]
animation gif

Comment 2

7 years ago
This happens to me too on windows vista (sp2) with a core2 duo  e8400 (3GHz) when I use the aero theme (which is the system default theme); the problem seems to disappear if I enable hardware acceleration or if I use a non transparent theme like vista basic.  

Mozilla/5.0 (Windows NT 6.0; rv:2.0b6pre) Gecko/20100912 Firefox/4.0b6pre
Status: UNCONFIRMED → NEW
Ever confirmed: true
Testing with d2d/dw 'off' I find the possible regression range as:

20100827194434 404b79632ff4 16% CPU

20100827215055 be857a136ffd 30-40% CPU 

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-08-27+19%3A44%3A34&enddate=2010-08-27+21%3A50%3A55+

I don't see anything obvious as to which patch may be the problem.
Keywords: regression
Here is a good example:

http://www.gamepron.com/news/2010/09/07/scott-pilgrim-vs-the-world-free-pixel-art/

Lots of animated gifs. Their framerates are degraded when they are all on the page at the same time. And Minefield is using 100% of 1 CPU core on my system to display all of those animated gifs.

Load one by itself and there is no problem at all:

http://www.gamepron.com/imagery/yeti.gif

Comment 5

7 years ago
There is some heavy thing going on 

http://forums.mozillazine.org/viewtopic.php?f=23&t=1990331

http://img801.imageshack.us/img801/566/namorokafine.png    (Namoroka Nightly)

http://img831.imageshack.us/img831/6941/minefieldprob.png (Minefield Nightly
and starting with Beta 2/ Beta 1 is ok no Kernel Explosion visible)

currently this site http://hcm.24h.com.vn/ almost kills Gecko 2.0b it stalls
the GUI because of the Windows Kernel Peaking

Comment 6

7 years ago
https://bugzilla.mozilla.org/show_bug.cgi?id=596441 <- Could be related to this also

Updated

7 years ago
Blocks: 596441
The regression range in comment 3 is a little puzzling. I wonder if someone else who sees this problem has the same regression range.
blocking2.0: --- → ?

Comment 8

7 years ago
Tomothy though the attached gif doesnt show this behaviour but comment 4 shows it very well it's @ the heaviest point the more GIFs are repainted on screen it causes the same Kernel Explosion as the Flash (wmode=true)problem combining those 2 test cases i guess is like what happens on the page we are currently puzzling about it's behaviour on Mozillazine forums i made a bug report for it https://bugzilla.mozilla.org/show_bug.cgi?id=596441 i linked both bugs to it, people now also start reporting about reduced Battery Life (with seems logic seeing this heavy 2 bugs drain energy like nothing else)
Tested on Linux using the attached animated gif here and got the cpu usage from the Ubuntu System Monitor. With the 2010-07-15 nightly I see 0-8 % cpu usage. With the 2010-07-16 nightly I see 16-24 % cpu usage. Looks like retained layers made this worse.
blocking2.0: ? → final+
Component: General → Graphics
Product: Firefox → Core
QA Contact: general → thebes

Updated

7 years ago
No longer blocks: 596441

Comment 10

7 years ago
I looked @ this and compared the beahviour to other renderer Opera,IE8,Chromium,Firefox (Minefield, Namoroka)

it's interesting but Minefield is not the only one currently fighting with cpu resource problem here (though Kernel should never be touched that heavy)

Chromium 40%
Opera 40%
Minefield 50% (definetly a bug due to heavy Kernel usage)
Namaoroka 8-10%
IE8 8-10%

so Namoroka and Ie8 are the most efficiently when it's about redrawing lot of GIF animations on screen in Windows :)

Minefield with D3D9 on not only showed the 50% Cpu utilization and heavy kernel usage but also the Animations where very slowly redrawn compared to the CPU method.

So all in all it seems to be small regresions but when they started is a good question i guess theres no way as to start @ Namoroka and see where the GIF redraw became so uneficient on Windows.

Comment 11

7 years ago
Here the results, most efficient from top to bottom :)

http://img832.imageshack.us/img832/2928/ie8gif.png
http://img841.imageshack.us/img841/3656/namorokagif.png
http://img641.imageshack.us/img641/3756/chromiumgif.png
http://img408.imageshack.us/img408/9465/operagif.png
http://img820.imageshack.us/img820/5659/minefieldbeta1.png
http://img46.imageshack.us/img46/7020/minefieldnightly.png

interesting how Microsofts Trident does it lowest CPU but therfore Kernel and CPU are @ the same usage :P

Comment 12

7 years ago
The actual regression window for GIF animation slow-down is the following:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2968d19b0165&tochange=29a6a85fab8e

It regressed between the April 26 and April 27 nightly builds.

Possible candidates are:
Bug 559660, Bug 542605, Bug 561827, and Bug 542605

Comment 13

7 years ago
I narrowed down regression range using this exsample http://www.gamepron.com/news/2010/09/07/scott-pilgrim-vs-the-world-free-pixel-art/


CPU(C2Q8300) 2-5%
http://hg.mozilla.org/mozilla-central/rev/2968d19b0165
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100426 Minefield/3.7a5pre ID:20100426040533

CPU 15-25%
http://hg.mozilla.org/mozilla-central/rev/f236632a9747
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100426 Minefield/3.7a5pre ID:20100426084628

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2968d19b0165&tochange=f236632a9747

And I revert in local build.
2968d19b0165 : CPU 6-10%
e3e80935c165 : CPU 7-10%
f236632a9747 :CPU 22-25%

So, Bug 542605 causes the problem
Thanks for those regression ranges.

I wonder why there is a different regression range on Windows from the one I found on Linux. Alice what range does this regress for you on Linux?

Comment 15

7 years ago
(In reply to comment #14)
> Thanks for those regression ranges.
> 
> I wonder why there is a different regression range on Windows from the one I
> found on Linux. Alice what range does this regress for you on Linux?

On Window 7,I only tried range of comment #12. not comment #9.

Comment 16

7 years ago
I confirm regression range in Comment #9 using animation gif in comment #1 on Linux and Windows7.

however,the remarkable difference is not recognized with the sample url of comment #4 on Linux.

So.I guess,
Windows: regressed by Bug 564991 and Bug 542605
Linux : regressed by Bug 564991
So bug 542605 didn't cause any regression in cpu usage of animated gifs on linux then?

Comment 18

7 years ago
(In reply to comment #17)
> So bug 542605 didn't cause any regression in cpu usage of animated gifs on
> linux then?

yes.it is only my investigation.

Comment 19

7 years ago
Alice: were you able to confirm that Bug 564991, specifically, caused the comment 9 regression and not one of the other graphics-related check-in for that day?

For example, Bug 577992 or Bug 577631?

Comment 20

7 years ago
(In reply to comment #19)
> Alice: were you able to confirm that Bug 564991,
Windows: cached hourly build.
Linux: nightly build. I imitated comment 9.

Comment 21

7 years ago
OK.  Thanks.  Someone with sufficient rights should probably add blocking against 542605 and Bug 564991, so it gets noticed.
Blocks: 542605, 564991
IU, you can probably get editbugs rights.

Comment 23

7 years ago
(In reply to comment #22)
> IU, you can probably get editbugs rights.

How or who would I request that from?
You should have it now.

Comment 25

7 years ago
(In reply to comment #24)
> You should have it now.

Confirmed.  Thanks.

Updated

7 years ago
Keywords: perf

Updated

7 years ago
Depends on: 599546

Updated

7 years ago
Blocks: 599546
No longer depends on: 599546
Assignee: nobody → joe
OS: Windows 7 → Windows XP

Comment 26

7 years ago
This to me happens also with animated png, the page with the new throbber mockups for example http://www.stephenhorlander.com/pages/activity-circles/activityCircles-test.html takes my cpu usage to 50%.
So it seems to be a problem common to all animated images, not only gifs.

Comment 27

7 years ago
(In reply to comment #26)
> So it seems to be a problem common to all animated images, not only gifs.

That's because there's a major cairo performance regression.
What do you mean? Is there a bug for that?

BTW, i can confirm Comment 26 on Win7. Fx4 uses the whole core on that page.

Comment 29

7 years ago
(In reply to comment #27)
> (In reply to comment #26)
> > So it seems to be a problem common to all animated images, not only gifs.
> 
> That's because there's a major cairo performance regression.

This is bad, from what I understand the new throbber uses animated pngs, so we have excessive cpu usage when loading a page just because of the throbber animation.

Comment 30

7 years ago
(In reply to comment #28)
> What do you mean? Is there a bug for that?

See comment 13.  The cause is identified there.  On windows, it regressed since the landing of whatever cairo version that bug pertains to.  Cairo needs to be fixed.
Assignee: joe → jmuizelaar
(Reporter)

Comment 31

7 years ago
Is there any reason as to why this doesn't block Beta 7 or Beta 8?
We don't think we'll be able to get it done by then.
Whiteboard: [unscoped]
Assignee: jmuizelaar → chris.double
Blocks: 615063

Comment 33

7 years ago
Hi i made the Gif Animation Performance Problem a local testcase removing all the useless flash add base to avoid conflicts with other known flash issues.

http://www.mediafire.com/?ev9bc042uc4yb48

Comment 34

7 years ago
Created attachment 493683 [details]
Gif Animation Performance testcase

Comment 35

7 years ago
Created attachment 494008 [details]
Testcase no Gif loading

To give cleaner better test results avoiding https://bugzilla.mozilla.org/show_bug.cgi?id=595671

Comment 36

7 years ago
Comment on attachment 494008 [details]
Testcase no Gif loading

Wrong bug report sorry
Attachment #494008 - Attachment is obsolete: true

Comment 37

7 years ago
I'm noticing something strange about this bug.  In my regular profile, I no longer experience this bug -- even in safe mode; however, I still experience it with a brand new profile.

I'm still trying to figure out what the unique factor is.  That will hopefully point to whatever the actual cause is.

Comment 38

7 years ago
*** NOTE: These are my findings on Windows XP SP3 ***

After some investigation, I've found that disabling hardware acceleration (layers.accelerate-all;false) improves performance.  Ironic, isn't it? 

In terms of CPU utilization, the improvement is not quite as good as it was prior to the regression noted in comment 13; however, in terms of animation speed and UI lag, performance is comparable what it was prior to the regression.

First, the system specs:
------------------------
Motherboard: Asus M4A89GTD PRO USB 3
Memory: 4 GB DDR3 PC-12800
Processor: AMD Athlon II X4 630 (2.8 GHz)
Graphics: Integrated Radeon HD 4200 (AMD 890GX chipset)
Hard Drive: 1 TB WD10EARS
OS: Windows XP PRO SP3
Graphics Driver: Catalyst 10.12
DirectX 9.0c


All testing conducted using attachment 493683 [details] ("Gif Animation Performance testcase")

STR:
1. Download and unzip the testcase 
2. Start Minefield with a new profile
3. load gif-overload.htm
4. Scroll the page down so that nothing above the tile and text, "Man plays games on world's largest LED screen," (blue box on right-hand side) is visible.  The point is to have as many animations in view as possible
5. Note animation speed and CPU utilization
6. Click the File menu and quickly drag the mouse pointer up-and-down the menu list.  Note the UI responsiveness.
7. Disable hardware acceleration (layers.accelerate-all;false)
8. Restart the browser. "Quit" on session saving prompt
9. Repeat steps 3 to 6.


My results (December 19 build):
===============================

HW Acceleration enabled:
------------------------
CPU Utilization: 25-26 %
UI Responsiveness: Very laggy

HW Acceleration disabled:
-------------------------
CPU Utilization: 17-20 %
UI Responsiveness: reasonably responsive


For comparison, April 26 (pre-regression) results:
==================================================
CPU Utilization: 9-13 %
UI Responsiveness: responsive

Comment 39

7 years ago
Could someone please confirm (using the latest nightly build) that, with hardware acceleration disabled, performance is now what it was prior to this regression.

Use the attached testcase and compare your results with the April 26th nightly build.

Comment 40

7 years ago
(In reply to comment #39)
> Could someone please confirm (using the latest nightly build) that, with
> hardware acceleration disabled, performance is now what it was prior to this
> regression.

Never mind.  There's no improvement.  I do get the improved numbers, but it's only after some time.  So something strange is happening.  I'm still investigating.
Duplicate of this bug: 620287
Whiteboard: [unscoped] → [unscoped][soft blocker]
Whiteboard: [unscoped][soft blocker] → [unscoped][softblocker]

Comment 42

7 years ago
i can confirm that Animation speed on Windows XP with layers layers.accelerate-all = false is much faster now :) still the CPU utilization is pretty high but the overall animation speed improved same happened for the german playstation site de.playstation.com (no improvement in CPU utilization but rendering speed improved significantly in the flash, in that case though it's not dependent on layers.accelerate-all being true or false) very nice improvement overall :)

Comment 43

7 years ago
Somehow the whole browser seems more snapier not only those cases improved also loading times my 100 tab testcase everything improved :)
However I still experience severe issues with animated GIFs, to the extent that I have to use Adblock to block all GIFs on one particular forum I frequent, since otherwise Firefox with only one of these tabs open can quite happily consume most/all of one core of my C2D 2.4. 

I can only think that people's perceptions of this depends very much on the image choices of the sites they visit, as I was rather surprised to see the softblocker whiteboard tag added - since for me this would have been a next beta blocker, let alone betaN or final.

Don't get me wrong, I respect the fact that not everyone sees certain issues and so this may not be fixed before other issues - I'm just worried that there are going to be a fair number of people affected if this is present in the final release. (Hopefully I'll be proved wrong, if only because I doubt that your average Firefox user would know how to create manual adblock rules, like I've done to workaround the situation).

Comment 45

7 years ago
Yes if you compare the CPU Utilization with the Namoroka trunk you will see that it's still lighter on the CPU utilization than current Minefield :(

Minefield = 50%
Namoroka = 30%

Comment 46

7 years ago
still Microsoft beats it http://img832.imageshack.us/img832/2928/ie8gif.png

Comment 47

7 years ago
so the headrom with Namoroka is higher that is most probably what you experience in your use case surfing a lot of GIf i would say your currently best of with IE ;) though i didn't compared the other browsers since https://bugzilla.mozilla.org/show_bug.cgi?id=595671#c11

Comment 48

7 years ago
Opera also improved very significantly they are up to Microsoft now with 0 Kernel utilization :) http://img560.imageshack.us/img560/9307/operaimproved.png
(In reply to comment #42)
> i can confirm that Animation speed on Windows XP with layers
> layers.accelerate-all = false is much faster now :) still the CPU utilization
> is pretty high but the overall animation speed improved same happened for the
> german playstation site de.playstation.com (no improvement in CPU utilization
> but rendering speed improved significantly in the flash, in that case though
> it's not dependent on layers.accelerate-all being true or false) very nice
> improvement overall :)

That is surprising. Do you know which nightlies this improvement happened between? I don't know of anything recently that should have made this big of a difference.

Comment 50

7 years ago
I gonna try to find out but this subjective improvement is without IPC i generally don't test with it in its current state.

Comment 51

7 years ago
and i could swear really that also tab loading improved :)

Comment 52

7 years ago
though de.playstation.com still shows some problems @ scrolling its really hacky maybe i should open another report for that though the site itself is very complex

Comment 53

7 years ago
Created attachment 502424 [details]
Gif Animation Performance testcase (similar to CruNcher's, but without all the formatting and JavaScript)

Here's a cleaner version of CruNcher's testcase (containing no formatting, JavaScript or links to external active content).

This should help with consistency, as I was getting inconsistent numbers with the previous testcase.
Attachment #493683 - Attachment is obsolete: true

Comment 54

7 years ago
Another problem encounter.

not only the animated image in website would trigger the problem, but also the loading status animated favicon in tabs.

4 or more loading states tab would take more than 40% cpu in my Athlon 64 3200+

Comment 55

7 years ago
(In reply to comment #54)
> Another problem encounter.
> 
> not only the animated image in website would trigger the problem, but also the
> loading status animated favicon in tabs.
> 
> 4 or more loading states tab would take more than 40% cpu in my Athlon 64 3200+

I mean, if you has an old machine, you thought you would skip this bug by setting play "once" or "never" to stop this issue own to web page's animated images, but not the program throbber, it's annoying when sometime got connection issue website, 4 or more loading page slow down the program because of the loading indicator, that is ironic.

Comment 56

7 years ago
Current Minefield (51 MB) = http://img16.imageshack.us/img16/2927/gifresultminefield.png
Current Namoroka (66 MB) = http://img412.imageshack.us/img412/9084/gifresultnamoroka.png

The Namoroka result really blown me away really good work whoever is responsible for this we just can hope that Minefield makes that code switch soon too :)
** PRODUCT DRIVERS PLEASE NOTE **

This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons:

 - it was marked as a soft blocking issue without a requirement for beta coverage
blocking2.0: final+ → .x+

Comment 58

6 years ago
Created attachment 518346 [details]
cpu useg on my computer goto 99% and gifs animation slows down
(Reporter)

Comment 59

6 years ago
ETA?

Comment 60

6 years ago
On the forums with animated emoticons load processor under 100%. Please fix it.
Duplicate of this bug: 645761
Blocks: 645761

Comment 62

6 years ago
(In reply to comment #4)
> Here is a good example:
> 
> http://www.gamepron.com/news/2010/09/07/scott-pilgrim-vs-the-world-free-
> pixel-art/
> 
> Lots of animated gifs. Their framerates are degraded when they are all on
> the page at the same time. And Minefield is using 100% of 1 CPU core on my
> system to display all of those animated gifs.
> 
> Load one by itself and there is no problem at all:
> 
> http://www.gamepron.com/imagery/yeti.gif

Comment 63

6 years ago
Firefox 4 and Firefox 5 using 100% of 1 CPU core (Athlon 2 215 - 2.7 Ghz) on my system to display animated gifs. Windows 7 or Windows XP - without a difference. Please, deal with a problem, it's very important for Firefox future.

Example

http://chat.vitebsk.ws/smile.php?name=kolobki2&jsclose=1&PHPSESSID=712fb5f997934bf52dbaf00e73fe81ea&

Comment 64

6 years ago
(In reply to comment #63)
> Firefox 4 and Firefox 5 using 100% of 1 CPU core (Athlon 2 215 - 2.7 Ghz) on
> my system to display animated gifs. Windows 7 or Windows XP - without a
> difference. Please, deal with a problem, it's very important for Firefox
> future.
> 
> Example
> 
> http://chat.vitebsk.ws/smile.
> php?name=kolobki2&jsclose=1&PHPSESSID=712fb5f997934bf52dbaf00e73fe81ea&

I have a core 2 duo 50%. What are your plans for the stabilization of a gif?

Comment 65

6 years ago
I can confirm this with Mozilla/5.0 (Windows NT 5.1; rv:7.0a1) Gecko/20110619 Firefox/7.0a1 (full specs here ==> http://pastebin.com/twdnStzf).
With hardware acceleration OFF it gets a little better (CPU at 40%-45% instead of 50%).
It feels like there are a bunch of issues tangle into one here. I've split off the chat.vitebsk.ws example into bug 666446.
Depends on: 666446
And bug 666449 for the problem pointing to the cairo update.
Depends on: 666449
Duplicate of this bug: 484793

Updated

6 years ago
Assignee: chris.double → nobody

Comment 69

6 years ago
I guess this is why it wasn't made a hard blocker, since on most modern systems it won't slow the machine down to a crawl, only saturating one core - it's still a severe problem though.

Any idea yet why it saturates one available core and only one? Because that's what I see happening; 25% on quad-core, 50% on dual-core, 100% on single-core. So it seems to be something that is limited to a single instance of a process (on one CPU thread) that this all ties in to, that every single GIF on a page has to use.
(In reply to Mark Straver from comment #69)
> Any idea yet why it saturates one available core and only one?

That's not a GIF-specific thing -- it's a Firefox-specific thing.  Most of Firefox is single-threaded, so generally it can max out at most one core.

(jwir3 is making great progress on patches to help out the situation with GIFs over on bug 666446)

Comment 71

6 years ago
(In reply to Daniel Holbert [:dholbert] from comment #70)
> (jwir3 is making great progress on patches to help out the situation with
> GIFs over on bug 666446)

Ah, I'm following that one as well, but I haven't seen any further updates recently on that bug - good to hear there's progress!

Thanks for explaining the single-threaded nature of Firefox; I'm a little surprised about that really, but I guess parallelizing is tricky.

Comment 72

6 years ago
(In reply to Mark Straver from comment #69)
> 25% on quad-core, 50% on dual-core, 100% on single-core.
> Any idea yet why it saturates one available core and only one?

(In reply to Daniel Holbert [:dholbert] from comment #70)
> That's not a GIF-specific thing -- it's a Firefox-specific thing.  Most of
> Firefox is single-threaded, so generally it can max out at most one core.

Then the problem can in a way be considered twice as severe on dual-core systems and 4 times as severe on quad-core systems, since saturating the one and only core that runs Firefox is 2 times easier and 4 times easier, respectively.

Speaking of %, there's a huge difference between 0% and even a small "normal" non-saturated processor load of, say, 10%. When the System Idle Process gets around 99% processor time, which it often does while running well-behaving programs (including a newly started Firefox!), the fan of most laptops nowadays can be kept silent most of the time. But when other processes constantly take around 10% or more, then there often is a dramatic increase in fan noise, and - probably even worse - it never turns off. This is actually a big health problem, considering how many users we have.
(Reporter)

Comment 73

6 years ago
Smilies on regular forum reply pages do not max out my netbook CPU anymore - the smilies are now able to animate at normal speed. CPU is still much higher than the competition who idle.

Comment 74

6 years ago
Oh no it's back in the current nightlies on Win7 32bit though :( 1 Entire core instead of half a core with the fix @ 2010-10-07 :(

Comment 75

6 years ago
64bit is also affected :(
(In reply to CruNcher from comment #74)
> Oh no it's back in the current nightlies on Win7 32bit though :( 1 Entire
> core instead of half a core with the fix @ 2010-10-07 :(

This is expected, on that date bug 666446 was backed out due to other regressions (https://bugzilla.mozilla.org/show_bug.cgi?id=666446#c381) and it has not yet relanded.

Comment 77

6 years ago
Oh ok thx good to know :)
I believe this has been fixed with the landing of bug 666446. Please reopen if I am incorrect.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Duplicate of this bug: 687978

Comment 80

5 years ago
Firefox 12.0 Linux 64bit is also affected
Comment hidden (spam)
You need to log in before you can comment on or make changes to this bug.