Closed
Bug 615063
Opened 14 years ago
Closed 13 years ago
Pages with huge amount of animated gif images causes high CPU load
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 666446
People
(Reporter: Nukeador, Unassigned)
References
()
Details
(Keywords: perf, regression)
Attachments
(2 files)
We are getting reports about high CPU load while visiting pages with huge amount of animated gif images.
The problems is reproducible under Windows XP using Firefox 4.0b7, with 3.6 branch CPU load is ok.
Original report: http://www.mozilla-hispano.org/foro/viewtopic.php?f=37&t=9454 (es)
Note that I wasn't able to reproduce the bug under Linux 64b, neither juanb under Windows 7.
Reporter | ||
Updated•14 years ago
|
Comment 1•14 years ago
|
||
imagelib or graphics (but never product Firefox)
Component: File Handling → ImageLib
Product: Firefox → Core
QA Contact: file.handling → imagelib
Comment 2•14 years ago
|
||
If you can reproduce, can you hunt down the regression range?
Keywords: regressionwindow-wanted
Comment 3•14 years ago
|
||
Was about to file something I believe is now related.
Using a MyBB forum "create new post" page, CPU usage for me using the last few weeks worth of Minefield nightlies was being reported as high as 30-40% for as long as that particular page was open, whereas usage with 3.6.12 or Chrome is more like 0-2%.
The forum install in question is on a private intranet, so I cannot link to it here, but will attach a reduced testcase that I derived from it (which contains just the animated emoticon GIFs). There are ~20 GIFs, so will have to put everything in an archive.
Exists in the latest nightly:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101127 Firefox/4.0b8pre
Comment 4•14 years ago
|
||
Comment 5•14 years ago
|
||
Comment 6•14 years ago
|
||
Regression range...
Works: http://hg.mozilla.org/mozilla-central/rev/e1d55bbd1d1d (2010-08-27)
Doesn't: http://hg.mozilla.org/mozilla-central/rev/6e3f6d18c124 (2010-08-28)
Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e1d55bbd1d1d&tochange=6e3f6d18c124
(Smallest I can get it now that hourlies not available, sorry!)
Comment 7•14 years ago
|
||
Per that Range this is probably a Dupe of Bug 595671, no?
Comment 8•14 years ago
|
||
Possibly. However that bug mentions two different regression ranges. The first in April and the second in August. Not sure where the April comes from?
Also to add to this bug, doesn't seem to occur if hardware acceleration unchecked if prefs.
Comment 9•14 years ago
|
||
> doesn't seem to occur if hardware acceleration unchecked if prefs.
OK, that's different from bug 595671.
Rubén, do you see that too? Or is Ed seeing something different from what you reported?
Reporter | ||
Comment 10•14 years ago
|
||
I'll ask the original reporter at our forums and report back here the results.
Reporter | ||
Comment 11•14 years ago
|
||
Sorry, I can't find which values should I ask them to uncheck at about:config to disable hardware acceleration.
Comment 12•14 years ago
|
||
If you filter about:config on "layers" you see two boolean prefs. Flip them both, so that layers.accelerate-all is false and layers.accelerate-none is true.
Reporter | ||
Comment 13•14 years ago
|
||
The answer from user was that with hardware acceleration disabled, the result is the same.
Comment 14•14 years ago
|
||
My apologies, the last sentence in comment 8 should have read "checked" not "unchecked". Also, with further testing, it would appear that the problem still does exist when hardware acceleration enabled, just to a lesser extent.
ie...
Testing with:
- Testcase from comment 5
- Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101129 Firefox/4.0b8pre
layers.accelerate-none = true
layers.accelerate-all = false
= cpu usage @ 38-47%
layers.accelerate-none = false
layers.accelerate-all = true
= cpu usage @ 10-25%
Comment 15•14 years ago
|
||
Also (sorry for bugspam), it would appear that unticking "enable hardware acceleration" in prefs only flips one of the prefs (layers.accelerate-none), rather than both. Is this intentional? (Given that numerous times on bmo have I seen people refer to it flipping them both, when it's not actually doing so in the latest nightly).
Comment 16•14 years ago
|
||
The pref behavior sounds right, yes. OK, so hardware acceleration makes the painting faster, so CPU usage is less... that part at least makes sense. :)
We should probably remeasure once bug 595671 is fixed, unless someone wants to hunt down the April regression range.
Comment 17•14 years ago
|
||
The more I look at this vs bug 595671, the more I think they are the same thing, unless I'm missing something?
In that bug an April regression range is mentioned:
https://bugzilla.mozilla.org/show_bug.cgi?id=595671#c13
...but not sure how that fits in?
Anyway, just say if I can help with tracking down regression ranges, it's about all I can contribute currently, sorry!
Comment 18•14 years ago
|
||
The only mention of an April regression range in this bug are comments 8, 16, and 17. Comment 8 is refering to bug 595671, so I think we might be going in circles here.
Comment 19•14 years ago
|
||
OK. So let's wait on bug 595671 and not worry about the April thing for now.
Ed, there's nothing to be sorry for. Tracking down regression ranges is really really useful!
Updated•14 years ago
|
Comment 22•14 years ago
|
||
May I add that deactivating hardware acceleration makes the page a bit faster, but not as smooth as it should be.
Comment 23•13 years ago
|
||
I'd like to add that I ran into the same bug (slow animations/100%CPU) going to http://loadinfo.net -- and on my system (single core 2.4 GHz Athlon64 w/ ATI HD3650, Radeon 11.6 drivers) it made really no difference if hardware acceleration was enabled or disabled (and it occurs on both my WinXP and Win7 x64 installations in v 5.0). The v3.6 installation that I run beside it has no issues with the same page on either O.S.)
Comment 24•13 years ago
|
||
(In reply to Mark Straver from comment #23)
> I'd like to add that I ran into the same bug (slow animations/100%CPU) going
> to http://loadinfo.net -- and on my system (single core 2.4 GHz Athlon64 w/
> ATI HD3650, Radeon 11.6 drivers) it made really no difference if hardware
> acceleration was enabled or disabled (and it occurs on both my WinXP and
> Win7 x64 installations in v 5.0). The v3.6 installation that I run beside it
> has no issues with the same page on either O.S.)
Just to offer another datapoint, on a single-core s754 Sempron 3100+ (1.9GHz) with a Geforce 6800 and latest stable driver and DX9 layers acceleration on Windows XP, the above page results only in 18-22% of CPU load and the playback is smooth.
Comment 25•13 years ago
|
||
Ed, are you still seeing this issue in Aurora or Nightly now that Bug 595671 is fixed?
Comment 26•13 years ago
|
||
I have Pentium 4 (Prescott 2M) 3.2 GHz and 2GB RAM based computer with WinXP 32bit SP3 and all latest updates. My videocard is NVIDIA FX-5200 based with latest driver from NVidia.
Firefox 10b4 eats all the CPU resources and animated GIF-s are moving very slow when the http://loadinfo.net webpage is opened. The same webpage works smoothly, without inhibition and don't eats all the CPU when I open it on IE6.
Comment 27•13 years ago
|
||
(In reply to Ali Juma [:ajuma] from comment #25)
> Aurora or Nightly now that Bug 595671 is fixed?
Rostislav, that means you'll have to use an 11.0a2 or a 12.0a1 build to verify if this issue is resolved (and it's actually bug 666446 that should have fixed this, which got backed out and checked in again later).
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/
Comment 28•13 years ago
|
||
(In reply to Rostislav Krasny from comment #26)
> I have Pentium 4 (Prescott 2M) 3.2 GHz and 2GB RAM based computer with WinXP
> 32bit SP3 and all latest updates. My videocard is NVIDIA FX-5200 based with
> latest driver from NVidia.
>
> Firefox 10b4 eats all the CPU resources and animated GIF-s are moving very
> slow when the http://loadinfo.net webpage is opened. The same webpage works
> smoothly, without inhibition and don't eats all the CPU when I open it on
> IE6.
I can verify that on WinXp 32bit SP3 with Pentium 4 2.4GHz with 3 GB Ram with all latest updates. Using Graphics Card Nvidia 7800GS with latest drivers.
Using latest Aurora or Nightly builds when viewing url http://loadinfo.net the page at first load spikes CPU between 40% > 50% then resides down to 20% > 30%, so I assuming this issue has been fixed and can be marked Resolved Fixed when Fx 11 goes to beta if not sooner.
Comment 29•13 years ago
|
||
(In reply to rsx11m from comment #27)
> Rostislav, that means you'll have to use an 11.0a2 or a 12.0a1 build to
> verify if this issue is resolved (and it's actually bug 666446 that should
> have fixed this, which got backed out and checked in again later).
>
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/
Ok, I'll try one of those alpha builds. If this issue is fixed there, will the fix be backported to the final 10.0 or maybe future 10.0.1 version of Firefox? If it won't, to wich version should I downgrade Firefox on my computer, until the final 11.0 version isn't released?
Comment 30•13 years ago
|
||
(In reply to Rostislav Krasny from comment #29)
> Ok, I'll try one of those alpha builds. If this issue is fixed there, will
> the fix be backported to the final 10.0 or maybe future 10.0.1 version of
> Firefox? If it won't, to wich version should I downgrade Firefox on my
> computer, until the final 11.0 version isn't released?
AFAIK, this will be in the v11 release. If you want to avoid this issue until then, you have to go back to version 3.6.x until the release of v11.
Comment 31•13 years ago
|
||
I've installed Firefox 11.0a2 and I confirm that this bug is fixed in that build. CPU load on my system, when the http://loadinfo.net is openned, is between 14% to 18%. Also the page itself is being loaded much quickly.
Comment 32•13 years ago
|
||
OK, in that case, we'll call this a duplicate. Hooray!
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•