Closed Bug 595671 Opened 14 years ago Closed 13 years ago

Animated images (GIFs) cause severe performance issues

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- .x+

People

(Reporter: alexandre.rogozine, Unassigned)

References

Details

(Keywords: perf, regression, Whiteboard: [unscoped][softblocker])

Attachments

(3 files, 2 obsolete files)

animation gif
5.25 KB, text/html
Details
Gif Animation Performance testcase (similar to CruNcher's, but without all the formatting and JavaScript)
1.13 MB, application/zip
Details
cpu useg on my computer goto 99% and gifs animation slows down
542 bytes, text/html
Details 
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.
Attached file animation gif — 

    
    

    
  
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.

    
    

    
  
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

    
    

    
  
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

    
    

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

    
  
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: --- → ?

    
    

    
  
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

    
  
No longer blocks: 596441

    
    

    
  
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.

    
    

    
  
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

    
    

    
  
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?

    
    

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

    
    

    
  
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?

    
    

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

    
    

    
  
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?

    
    

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

    
    

    
  
OK.  Thanks.  Someone with sufficient rights should probably add blocking against 542605 and Bug 564991, so it gets noticed.

    
    

    
  
IU, you can probably get editbugs rights.

    
    

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

    
    

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

Confirmed.  Thanks.
Keywords: perf
Depends on: slowui
Blocks: slowui
No longer depends on: slowui
Assignee: nobody → joe
OS: Windows 7 → Windows XP

    
    

    
  
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.

    
    

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

    
    

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

    
    

    
  
(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

    
    

    
  
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

    
    

    
  
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

    
    

    
  

      
      
      
      

        Attached file
          
        Gif Animation Performance testcase (obsolete)
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached file
          
        Testcase no Gif loading (obsolete)
        — 
      

    


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

    
    

    
  
Comment on attachment 494008 [details]
Testcase no Gif loading

Wrong bug report sorry

        Attachment #494008 -
        Attachment is obsolete: true

    
    

    
  
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.

    
    

    
  
*** 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

    
    

    
  
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.

    
    

    
  
(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.
Whiteboard: [unscoped] → [unscoped][soft blocker]
Whiteboard: [unscoped][soft blocker] → [unscoped][softblocker]

    
    

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

    
    

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

    
    

    
  
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%

    
    

    
  
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

    
    

    
  
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.

    
    

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

    
    

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

    
    

    
  
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

    
    

    
  


  
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

    
    

    
  
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+

    
    

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

    
    

    
  
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+

    
    

    
  
ETA?

    
    

    
  
On the forums with animated emoticons load processor under 100%. Please fix it.
Blocks: 645761

    
    

    
  
(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

    
    

    
  
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&

    
    

    
  
(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?

    
    

    
  
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

    
  
Assignee: chris.double → nobody

    
    

    
  
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)

    
    

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

    
    

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

    
    

    
  
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.

    
    

    
  
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 :(

    
    

    
  
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.

    
    

    
  
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
Closed: 13 years ago
Resolution: --- → FIXED

    
    

    
  
Firefox 12.0 Linux 64bit is also affected

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
  
Hello Folks. Due to the amount of spam comments this bug is attracting I am restricting comments on this bug. If you are experiencing a bug with GIF performance please file a new bug.


Restrict Comments: true

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: