Just go to http://corp.pixel-industries.com/index2.html and watch the CPU at 100%. Though having a 1.1ghz, 327 ram this page is causing some major problems. Any idea what is causing this?

I see this as well on my 850 MHz / 512 MB machine. Saving the animated GIFs to file, and viewing them with IrfanView sucks less than 10% CPU. So I guess Mozilla doesn't render animated GIFs very efficiently... Dupe of bug 86319 ?

one big culprit on the page is: http://corp.pixel-industries.com/generator/images/bt_background.gif which makes me suspect this is a dup of bug 86319 will tests more...

http://corp.pixel-industries.com/generator/images/bt_background.gif takes up 100% when loaded on it own. http://corp.pixel-industries.com/generator/images/img_05.gif takes about 40% http://corp.pixel-industries.com/generator/images/img_06.gif takes about 10% to 15% the rest take less than 10% most of the time. these 4 take very little CPU power when loaded individually, however when loaded on page togather I can get from 50% to 100% of CPU usage. http://corp.pixel-industries.com/generator/images/img_screen_01.gif http://corp.pixel-industries.com/generator/images/img_screen_02.gif http://corp.pixel-industries.com/generator/images/img_screen_03.gif http://corp.pixel-industries.com/generator/images/img_screen_04.gif

the 100% from the last case turn out to be just noise, I can't seem to repro the 100% but I can consistently get about 50%

Here's a VERY interesting observation about http://corp.pixel-industries.com/generator/images/bt_background.gif: On a dual-450 PIII Linux machine, I see almost NO time used by Mozilla, and about 17% of a PIII-800 machine being used by the X11 server (that draws the bits). This means it's the actual drawing operations that are taking the time for us (at least in unix). On a slow machine (233MHz MMX 64MB Win95) running an older build, I see 100% CPU use and it runs slowly. However, on that same machine, IE 5.01 (note) starts at about 10% cpu use, but the CPU use climbs in a straight line to 100% quite quickly (2-3 seconds) and remains there, and the animations gets slower and slower (no disk activity). Then, when it cycles (takes a while), suddenly CPU use drops to 10% and starts climbing again. This tells me that IE is, for each frame of a transparent animation, compositing ALL the frames leading up to it (in some fashion). For a large number of frames (this anim certainly has a large number) this means it runs slower and slower... but without a massive memory hit.

I couldn't run this for more than ~30 seconds because it crashes jprof (reported in another bug for dbaron already), but I got a jprof: Lots of region creation/clipping. Lots of pushing/popping rendering states (around 15%). Some creation/optmization of display lists. FindBackground() seems to take more time than I'd think A LOT more NewURI's in LoadImage than I'd think (which ends up using around 8-9%) ~5% in UpdateGC (from FillRect, etc) 50% in PaintChild() (no surprise other than it wasn't more (percentage-wise)) Only about 5% is in nsImageGTK::Draw() - around the same amount we use getting the imagemap. malloc/free use close to 20%.

The page http://www.nanopops.de/history/content.html is causing a very tough-responding mouse-cursor. This can also be seen by just viewing the image http://www.nanopops.de/history/images/4.gif using build 2002030908 on win-xp, 1.1ghz

See also the discussion in bug 126445, where the relative merits of rendering animated images one frame at a time are discussed.

Those two websites can hardly be used by Mozilla: http://english.jmail.co.jp/cgi-bin/24e.cgi and http://www.t-online.de/ On the first webpage when I try to log in Mozilla eats 100% CPU time for up to a second for every character I type in. This even happens when I configure Mozilla not to loop animated GIFs ! The only way to work around this bug seeems to keep Mozilla from loading (those) images :-(

*** This bug has been marked as a duplicate of 86319 ***

Verified Duplicate