Page is using up 100% cpu. This may be a dupe but I couldnt see anything exactly matching the description. I suspect its an image rending problem as if you scroll to the bottom of the page where there are less images the cpu usage drops.
Sorry, this is in build 2001091403
With a 600MHz Athlon, I don't see 100% CPU usage, but it does hover around 40%, which is quite high. And Mozilla's response when I try to scroll is definitely impaired. More significant is that NS 4.x shows CPU usage around 7%, and there is no slowdown in scrolling.
using 0.9.4 i dont have a problem on that page, BUT i have the same problem on the w3 css page http://www.w3.org/Style/CSS/
No dupes found. Confirming and marking NEW. (For me, Mozilla used about 70% CPU on an Athlon 728 MHz)
Status: UNCONFIRMED → NEW
Ever confirmed: true
If I change my default background colour to ie pink, I can see an area at the top of the page changing colours from white to pink an back again repeatedly.
Hmm, just duplicaed the flashing bar here (but not in IE or opera). What I have noticed though is that the page initially sticks up a loading screen thats basically a tiled (possibly animated) image before displaying the main menu.On IE it seems to overlay the menu on top and so obscuring it. Is it possible that Moz is still refreshing this background?
Sorry, just noticed bugzilla got rid of the keywords last time..
Looks like something funny with that background image. attaching testcases and moving to imagelib. I've narrowed it down to what I think is the most simplified testcase that still reproduces a CPU spike (note, my cpu goes up to about 40%, back to 0% then up to 40% again, cycling like this when I view the full page and when I view the testcase) <html> <body BACKGROUND="http://www.7dayshop.com/acatalog/loading.gif"> </body> </html> The reason I think this is an image problem is that when I replace that gif with mozilla-banner.gif I don't see the CPU spiking.
Assignee: asa → pavlov
Component: Browser-General → ImageLib
QA Contact: doronr → tpreston
Created attachment 50259 [details] body BACKGROUND="http://www.7dayshop.com/acatalog/loading.gif" which demonstrates a cycling CPU spike
Created attachment 50260 [details] <body BACKGROUND="http://www.mozilla.org/images/mozilla-banner.gif"> which doesn't cause CPU spike
http://www.livingingreytown.com/comics/grey20010919.gif Above image used 100% of CPU on an Athlon 1gighz, running win2k. Reported by webart to have used 30% of his under Linux (who knows, might've had a build goin on at the same time, or maybe Linux code marginally better written? :) ) Build ID - 2001091303 - Fell back to official 0.9.4 release at the moment, I think...
loading.gif is an animated gif file but for whatever reason it does not seem animate in mozilla. Note that I don't see 100% CPU usage just about 30+% and only when the page is visible. I have a feeling that this might have more to do with the tiling of the image as when I load the image on its own the CPU usage stays at 0%. this was tested using build 2001091303 win32 on win2k
This http://www.livingingreytown.com/comics/grey20010919.gif also happens to be an animated gif.
Summary: 100% CPU usage on page → animated gif causes high (sometimes 100%) CPU usage
I still 100% CPU usage with win XP build on the original URL and http://www.livingingreytown.com/comics/grey20010919.gif
this might be a dup of bug 86319
http://www.livingingreytown.com/comics/grey20010919.gif is trying to animate a 733x238 frame every 0.01s.. that's 100 frames a second. Even Animation Shop uses 100% of my CPU when trying to animate the gif. http://www.7dayshop.com/acatalog/loading.gif is File Not Found.. can't test.
Just built with the patch in bug 125137 (attachment 70577 [details]) on a P3/500 running Linux, XFree86 4.1.0 Testing http://www.livingingreytown.com/comics/grey20010919.gif : CPU usage before patch: X 47.0%, mozilla-bin 41.2% -> Total: 88,2% CPU usage after patch: X 11.1%, mozilla-bin 39.0% -> Total: 50,1%
Ooops.. that was the patch in attachment 70180 [details] [diff] [review] - (not 70577, which is a gif)
reopen if you think otherwise. *** This bug has been marked as a duplicate of 86319 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.