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)

x86
Windows XP
defect
Not set
normal

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.
imagelib or graphics (but never product Firefox)
Component: File Handling → ImageLib
Product: Firefox → Core
QA Contact: file.handling → imagelib
If you can reproduce, can you hunt down the regression range?
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
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!)
Per that Range this is probably a Dupe of Bug 595671, no?
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.
Depends on: 595671
> 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?
I'll ask the original reporter at our forums and report back here the results.
Sorry, I can't find which values should I ask them to uncheck at about:config to disable hardware acceleration.
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.
The answer from user was that with hardware acceleration disabled, the result is the same.
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%
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).
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.
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!
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.
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!
May I add that deactivating hardware acceleration makes the page a bit faster, but not as smooth as it should be.
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.)
(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.
Ed, are you still seeing this issue in Aurora or Nightly now that Bug 595671 is fixed?
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.
(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/
(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.
(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?
(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.
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.
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.

Attachment

General

Created:
Updated:
Size: