Last Comment Bug 595671 - Animated images (GIFs) cause severe performance issues
: Animated images (GIFs) cause severe performance issues
Status: RESOLVED FIXED
[unscoped][softblocker]
: perf, regression
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: unspecified
: x86 Windows XP
: -- major with 52 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 484793 620287 687978 (view as bug list)
Depends on: 666449 666446
Blocks: slowui 542605 564991 615063 645761
  Show dependency treegraph
 
Reported: 2010-09-12 10:00 PDT by Alex
Modified: 2016-06-13 23:49 PDT (History)
69 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
.x+


Attachments
animation gif (5.25 KB, text/html)
2010-09-12 11:33 PDT, Alice0775 White
no flags Details
Gif Animation Performance testcase (1.44 MB, application/zip)
2010-11-29 07:51 PST, CruNcher
no flags Details
Testcase no Gif loading (256.51 KB, application/zip)
2010-11-30 08:35 PST, CruNcher
no flags Details
Gif Animation Performance testcase (similar to CruNcher's, but without all the formatting and JavaScript) (1.13 MB, application/zip)
2011-01-09 21:36 PST, IU
no flags Details
cpu useg on my computer goto 99% and gifs animation slows down (542 bytes, text/html)
2011-03-10 05:40 PST, Dariusz
no flags Details

Description Alex 2010-09-12 10:00:41 PDT
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 Alice0775 White 2010-09-12 11:33:30 PDT
Created attachment 474550 [details]
animation gif
Comment 2 Rampo 2010-09-12 11:44:52 PDT
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
Comment 3 Jim Jeffery not reading bug-mail 1/2/11 2010-09-12 12:58:34 PDT
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.
Comment 4 Brian Carpenter [:geeknik] 2010-09-13 16:35:59 PDT
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 CruNcher 2010-09-14 16:57:07 PDT
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 CruNcher 2010-09-14 17:39:50 PDT
https://bugzilla.mozilla.org/show_bug.cgi?id=596441 <- Could be related to this also
Comment 7 Timothy Nikkel (:tnikkel) 2010-09-15 12:21:08 PDT
The regression range in comment 3 is a little puzzling. I wonder if someone else who sees this problem has the same regression range.
Comment 8 CruNcher 2010-09-15 12:46:22 PDT
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)
Comment 9 Timothy Nikkel (:tnikkel) 2010-09-15 13:08:14 PDT
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.
Comment 10 CruNcher 2010-09-15 19:45:28 PDT
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 12 IU 2010-09-18 16:56:09 PDT
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 Alice0775 White 2010-09-18 23:00:37 PDT
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
Comment 14 Timothy Nikkel (:tnikkel) 2010-09-19 00:25:55 PDT
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 Alice0775 White 2010-09-19 00:30:26 PDT
(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 Alice0775 White 2010-09-19 01:07:42 PDT
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
Comment 17 Timothy Nikkel (:tnikkel) 2010-09-19 01:10:01 PDT
So bug 542605 didn't cause any regression in cpu usage of animated gifs on linux then?
Comment 18 Alice0775 White 2010-09-19 01:12:24 PDT
(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 IU 2010-09-19 01:33:13 PDT
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 Alice0775 White 2010-09-19 01:53:17 PDT
(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 IU 2010-09-19 01:58:22 PDT
OK.  Thanks.  Someone with sufficient rights should probably add blocking against 542605 and Bug 564991, so it gets noticed.
Comment 22 Timothy Nikkel (:tnikkel) 2010-09-19 02:01:35 PDT
IU, you can probably get editbugs rights.
Comment 23 IU 2010-09-19 09:57:30 PDT
(In reply to comment #22)
> IU, you can probably get editbugs rights.

How or who would I request that from?
Comment 24 Timothy Nikkel (:tnikkel) 2010-09-19 10:53:17 PDT
You should have it now.
Comment 25 IU 2010-09-19 11:31:41 PDT
(In reply to comment #24)
> You should have it now.

Confirmed.  Thanks.
Comment 26 Rampo 2010-10-13 01:09:13 PDT
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 IU 2010-10-13 06:28:31 PDT
(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.
Comment 28 Csaba Kozák [:WonderCsabo] 2010-10-13 07:31:52 PDT
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 Rampo 2010-10-13 07:51:12 PDT
(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 IU 2010-10-13 08:55:50 PDT
(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.
Comment 31 Alex 2010-10-14 15:01:19 PDT
Is there any reason as to why this doesn't block Beta 7 or Beta 8?
Comment 32 Joe Drew (not getting mail) 2010-10-14 15:07:17 PDT
We don't think we'll be able to get it done by then.
Comment 33 CruNcher 2010-11-29 07:50:10 PST
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 CruNcher 2010-11-29 07:51:32 PST
Created attachment 493683 [details]
Gif Animation Performance testcase
Comment 35 CruNcher 2010-11-30 08:35:26 PST
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 CruNcher 2010-11-30 08:37:16 PST
Comment on attachment 494008 [details]
Testcase no Gif loading

Wrong bug report sorry
Comment 37 IU 2010-12-18 23:30:37 PST
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 IU 2010-12-19 13:19:04 PST
*** 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 IU 2011-01-06 05:25:31 PST
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 IU 2011-01-06 05:57:54 PST
(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.
Comment 41 Joe Drew (not getting mail) 2011-01-06 11:52:35 PST
*** Bug 620287 has been marked as a duplicate of this bug. ***
Comment 42 CruNcher 2011-01-07 20:43:24 PST
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 CruNcher 2011-01-07 20:51:41 PST
Somehow the whole browser seems more snapier not only those cases improved also loading times my 100 tab testcase everything improved :)
Comment 44 Ed Morley [:emorley] 2011-01-07 20:57:29 PST
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 CruNcher 2011-01-07 21:13:11 PST
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 CruNcher 2011-01-07 21:14:09 PST
still Microsoft beats it http://img832.imageshack.us/img832/2928/ie8gif.png
Comment 47 CruNcher 2011-01-07 21:22:08 PST
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 CruNcher 2011-01-07 21:35:21 PST
Opera also improved very significantly they are up to Microsoft now with 0 Kernel utilization :) http://img560.imageshack.us/img560/9307/operaimproved.png
Comment 49 Timothy Nikkel (:tnikkel) 2011-01-07 22:00:54 PST
(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 CruNcher 2011-01-07 22:49:57 PST
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 CruNcher 2011-01-07 22:56:07 PST
and i could swear really that also tab loading improved :)
Comment 52 CruNcher 2011-01-07 23:04:34 PST
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 IU 2011-01-09 21:36:31 PST
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.
Comment 54 dindog 2011-01-20 05:50:07 PST
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 dindog 2011-01-24 19:16:35 PST
(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 CruNcher 2011-01-26 19:46:02 PST
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 :)
Comment 57 Mike Beltzner [:beltzner, not reading bugmail] 2011-03-03 07:22:03 PST
** 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
Comment 58 Dariusz 2011-03-10 05:40:56 PST
Created attachment 518346 [details]
cpu useg on my computer goto 99% and gifs animation slows down
Comment 59 Alex 2011-03-10 07:42:48 PST
ETA?
Comment 60 Hobbix 2011-03-23 08:26:20 PDT
On the forums with animated emoticons load processor under 100%. Please fix it.
Comment 61 Matthias Versen [:Matti] 2011-03-28 11:00:56 PDT
*** Bug 645761 has been marked as a duplicate of this bug. ***
Comment 62 sansan_qq 2011-05-26 07:34:15 PDT
(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 oleg.chijov 2011-06-19 03:35:45 PDT
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 adminnu 2011-06-19 07:54:44 PDT
(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 RNicoletto 2011-06-19 12:13:05 PDT
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%).
Comment 66 Jeff Muizelaar [:jrmuizel] 2011-06-22 17:09:20 PDT
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.
Comment 67 Jeff Muizelaar [:jrmuizel] 2011-06-22 17:14:06 PDT
And bug 666449 for the problem pointing to the cairo update.
Comment 68 Trif Andrei-Alin[:AlinT] 2011-08-11 05:37:35 PDT
*** Bug 484793 has been marked as a duplicate of this bug. ***
Comment 69 Mark Straver 2011-08-22 12:19:49 PDT
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.
Comment 70 Daniel Holbert [:dholbert] 2011-08-22 12:39:22 PDT
(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 Mark Straver 2011-08-22 13:02:28 PDT
(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 mr 2011-08-23 01:44:17 PDT
(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.
Comment 73 Alex 2011-10-06 13:53:09 PDT
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 CruNcher 2011-10-30 06:36:38 PDT
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 CruNcher 2011-10-30 06:37:56 PDT
64bit is also affected :(
Comment 76 Ed Morley [:emorley] 2011-10-30 06:40:51 PDT
(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 CruNcher 2011-10-30 06:55:46 PDT
Oh ok thx good to know :)
Comment 78 Scott Johnson (:jwir3) 2011-11-14 15:41:34 PST
I believe this has been fixed with the landing of bug 666446. Please reopen if I am incorrect.
Comment 79 Wayne Mery (:wsmwk, NI for questions) 2012-02-10 04:09:19 PST
*** Bug 687978 has been marked as a duplicate of this bug. ***
Comment 80 ajrodriguez 2012-05-31 01:28:08 PDT
Firefox 12.0 Linux 64bit is also affected
Comment 81 nhung.bry 2016-06-13 23:49:27 PDT Comment hidden (spam)

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