This large animated GIF causes mozilla to use 50% CPU (AMD K6-III 500) and makes mouse response function sporadically. It's only 2 frames, but is 1024x768 in dimensions. It was actually created to display unrelated bug 86301. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.1+) Gecko/20010617 (though my titlebar says 2001061504 (??))

Here's another image which is not dimensionally large, but is about 200k in filesize. http://www.kontek.net/404/enter.gif It also uses 50% CPU, but doesn't seem to affect performance unless it is not in focus. Then it affects mouse movement, sound playing, etc.

I see the same behavior in IE, so it can't be a bug.

Stats from a PIII-600 running Win2K-SP2 enter.gif uses 5% CPU using IE 5.5SP1 enter.gif uses 90% CPU using Netscape 4.77 enter.gif uses 100% CPU using Mozilla build 2001061720-trunk mozilla-bug1.gif uses 0% CPU using IE 5.5SP1 mozilla-bug1.gif uses 6% CPU using Netscape 4.77 mozilla-bug1.gif uses 100% CPU using Mozilla build 2001061720-trunk and the system becomes unusable may be two separate bugs based on statistics, but its definitely a Mozilla problem, not a universal problem.

Memory usage on enter.gif: * Linux Build ID = 2001011318 (13th Jan) : 600k * Linux Build ID = 2001062405 (25 Jun) : 3200k (took the VMSIZE measure from 'top')

nsbeta2->nsbeta1 mozilla0.9.2->mozilla0.9.3

dupe of bug 82278 ? Check out the url i supplied: http://www.digitalblasphemy.com/dbgallery/4/morninglight.shtml Try that one with IE, then netscape 4.77, then mozilla

No this bug doesn't have anything to do with that one. Your site doesn't use animated GIFs AFAICS. These graphics are not scaled. And besides.. your site works fine for me.

Both urls (mozilla-bug1.gif and enter.gif) only use around 20% cpu time on my 266MHz/256MB laptop in build #2001070421. Any changes anywhere?

AMD K6-III/500MHz,192MB RAM,WinXP Beta 2,Elsa Gladiac MX,2001070604-trunk mozilla-bug1.gif 45% CPU, but system still freezes enter.gif still 100% CPU, but system usable however, it shouldn't even be using 20%

As Martin suggests, it seems to be at least _partly_ a memory problem. DON'T TRY THIS ONE unless you have lots of RAM, or you really need to. Suggest renicing your shell to a low priority before running mozilla - might help wrestle control back. http://www.mids.org/weather/world/latest.html On my linux machine, with xfree86 4.1, top reports the following stats: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 4933 root 9 0 111M 101M 33872 S 0.1 23.1 14:34 mozilla-bin 4935 root 8 0 111M 101M 33872 S 0.0 23.1 0:00 mozilla-bin 4936 root 9 0 111M 101M 33872 S 0.0 23.1 0:00 mozilla-bin 4937 root 9 0 111M 101M 33872 S 0.0 23.1 0:00 mozilla-bin 988 root 11 0 157M 85M 6908 R 4.2 19.3 102:34 X mozilla-bin's rss drops down to 65M by itself after a few minutes. When I close the window it drops MASSIVELY to: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 4933 root 9 0 53252 35M 28704 S 0.1 8.0 14:43 mozilla-bin 4935 root 9 0 53252 35M 28704 S 0.0 8.0 0:00 mozilla-bin 4936 root 9 0 53252 35M 28704 S 0.0 8.0 0:00 mozilla-bin 4937 root 9 0 53252 35M 28704 S 0.0 8.0 0:00 mozilla-bin 6048 root 9 0 53252 35M 28704 S 0.0 8.0 0:00 mozilla-bin 1153 root 20 19 14716 12M 492 R N 31.7 2.9 5343m setiathome 988 root 9 0 85540 10M 6484 S 3.1 2.3 102:49 X Notice the dramatic drop in the X server's memory usage as well. Now I know top isn't necessarily the most accurate of process info tools, but xosview corroborates it and shows a massive overall memory usage increase, and then decrease when I close the window. summary: mozilla shouldn't try to grab a ridiculous amount of ram.

oops forgot to mention - my build id is 2001071608

I think overall animated GIF rendering performance has taken a hit. Check out viewer demos #7 and #10... they use 75-100% CPU and the scaled one freezes up the OS. The two testcases on this bug are also performing even worse than before. Both 100% and freeze up the system. [2001071903-trunk/Win2K/PIII-600/128MB]

libimg used to decode one frame in an animated gif and show it while decoding the next one and so on. This lead to lots of timing issues that were very difficult to deal with, and I guess that's at least partly why libpr0n got introduced. libpr0n decodes all frames of an animated gif and stores them into memory, and finally animates them. Hence, libpr0n uses a great approach to use for a PC with lots of RAM, but in an embedding situation it uses way too much memory. A proposal would be a pref that may be set by embedders that will make libpr0n revert to the old libimg approach, or? By the way, I just noticed that even when using user_pref ("image.animation_mode", "none"); libpr0n decodes all frames and allocates a lot of memory for them.

saw this on a 4 meg animated gif at http://www.albury.net.au/~rossw/codered.gif 2001072303 win2k my machine grinds to a halt when i try to view it. i experienced about 30 seconds of disk thrashing to bring up the second frame. ie6 beta had no issues displaying the same gif.

*** Bug 93546 has been marked as a duplicate of this bug. ***

This has regressed around mid-June. I checked with earlier builds that I have archived locally. It's a regression that occured between nightly builds from 2001-06-14-15-trunk and 2001-06-18-07-trunk dirs on ftp://ftp.mozilla.org. 2001-06-14-15-trunk renders smoothly, 2001-06-18-07-trunk eats CPU. I couldn't pinpoint the exact nightly build that regressed, because I have only those two builds I mentioned and on ftp://ftp.mozilla.org/pub/mozilla/nightly they are no more (ftp could use some more space for archival builds...). If you need another testcase, you can have a look at attachment 93546 [details] from my bug 93546 that was a dupe of this one.

Sorry, that was attachment 44627 [details].

marking regression per Aleksander's comments.. must be somewhere between 6/14 and 6/17 (notice original posting date)

Another Example http://www.lightning.ece.ufl.edu/storm.gif

Here's an animated gif of sea surface temperatures http://ingrid.ldeo.columbia.edu/SOURCES/.NOAA/.NCEP/.EMC/.CMB/.GLOBAL/.weekly/figviewer.html?my.help=&map.T.plotvalue=4+Nov+1981+to+1+Sep+2000&map.Y.units=degree_north&map.Y.plotlast=90N&map.url=a-+.ssta+-a+X+Y+fig-+colors+land+-fig&map.domain=+%7B+%2FT+3.+3.+plotrange+X+30.+390.+plotrange+%7D&map.domainparam=+%2Fplotaxislength+432+psdef+%2Fplotborder+72+psdef+%2FXOVY+null+psdef&map.zoom=Zoom&map.Y.plotfirst=90S&map.X.plotfirst=30E&map.X.units=degree_east&map.X.modulus=360&map.X.plotlast=30E&map.ssta.plotfirst=-4.2&map.ssta.units=degree_Celsius&map.ssta.plotlast=4.2&map.newurl.grid0=X&map.newurl.grid1=Y&map.newurl.land=draw+land&map.newurl.vars.0=.ssta&map.newurl.plot=colors&map.plotaxislength=432&map.plotborder=72&map.fnt=Helvetica&map.fntsze=12&map.color_smoothing=auto&map.antialias=on&map.XOVY=auto&map.iftime=25&map.mftime=25&map.fftime=200 Loads nicely in Netscape 4.77. In Mozilla 2001100506, it takes forever to load even though there is no swapping and CPU load stays a couple of percent. I have plenty of memory so the 446M that mozilla requires does not affect anything else.

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

*** Bug 113797 has been marked as a duplicate of this bug. ***

I can *not* verify that this has regressed between 6/14 and 6/17. I used 'cvs update' with the '-D' flag for the different dates and built two mozillas. I couldn't see any difference in memory usage nor CPU on http://www.kontek.net/404/enter.gif using the measures from 'top'.

What OS are you on? I were using win32 builds on Win 2K then.

Linux/Pentium III

Can anyone test whether actually win32 builds regressed on this bug between 2001-06-14 and 2001-06-18 ? I might be wrong in comment #16, but I usually double check things before submitting comments to bugzilla... I don't have those old builds anymore and I can't retest it now :-(.

*** Bug 120154 has been marked as a duplicate of this bug. ***

I'd like to note that this brings one of the two processors of my Dual Athlon XP 1700+ machine to 100%. Looking at taskmgr, nearly all of that percentage turns red (kernel time). Anybody have any ideas why it would be kernel time?

I'd like to note that the testcase causes CPU usage of about: 70% with Opera 6 100% with Mozilla build 2002020603 win32 trunk 0%-6% with IE5.01 on win32 70% with NS4.78 another thing I'd say is this, NS4 displays the animation the fastest, Moz comes in second, Opera and IE seems about the same. This was tested on Athlon 1.2GHz

*** Bug 94828 has been marked as a duplicate of this bug. ***

another one bringing mozilla down - http://corp.pixel- industries.com/index1.html

testcases: http://www.geekculture.com/geekycomics/Aftery2k/y2Kimages/403.gif http://corp.pixel-industries.com/generator/images/bt_background.gif http://corp.pixel-industries.com/generator/images/img_05.gif

Some numbers of a K6-III/400, 192MB, Win98 system, with 2002022308: http://www.geekculture.com/geekycomics/Aftery2k/y2Kimages/403.gif : 100% cpu usage, even when if the animated part is not visible (window minimized or animated part out of window boundaries). http://corp.pixel-industries.com/generator/images/bt_background.gif : 50%, about 5% when minimized. http://corp.pixel-industries.com/generator/images/img_05.gif : 15%, less than 4 % when minimized. _basic, I think it would be better if you attach those gifs in bugzilla. http://bugzilla.mozilla.org/attachment.cgi?id=47940&action=view : 100%, 50% after minimizing.

Dimitrios: this bug isn't about performance when the images are not visible. I'm not seeing the effect after minimizing. Please file a new bug and mention bug 125025. Feel free to CC me.

You 're right, numbers for minimized state should be posted to bug 120154, where you had been already cc'ed :). As for this bug, first number in each pair is the performance of a normal window, so I think it is valid. These numbers show that, for the 1st and 4th case, cpu usage is 100%.

*** Bug 130503 has been marked as a duplicate of this bug. ***

*** Bug 124999 has been marked as a duplicate of this bug. ***

migrating keywords

First of all, you can't really compare animation speed to IE until you set the .gif to 100ms frame rate delay, which is what IE and Opera do to all frame rates < 100ms. http://tgos.org/mozilla-bug1.gif does not exist anymore File ------> Moz |Moz2 |Moz3 | _IE http://www.kontek.net/404/enter.gif ------> 98% | 10% | 34% | 20% | 318x240; 11 Frames @ 10ms delay http://www.geekculture.com/geekycomics/Aftery2k/y2Kimages/403.gif ------> 99% | 70% | 99% | 24% | 600x900; 3 Frames @ 20ms delay http://corp.pixel-industries.com/generator/images/bt_background.gif ------> 33% | 10% | 33% | ??? | 336x317; 229 Frames @ 30 ms delay (IE acts wierd with this image.. starts at 10%, climbs up to 60%, then back down to 10% and repeats) http://corp.pixel-industries.com/generator/images/img_05.gif ------> ~1% | ~1% | ~1% | <1% | 364x187; 29 Frames @ no delay set (which cause Mozilla to display it at 100ms) Attachment 47940 [details] ------> 99% | 20% | 66% | ~1% | 280x344; 17 Frames @ 10ms delay Moz = Build 2002040708 Moz2 = Build 2002040708 w/gif set to 100ms delay (which is what IE does) Moz3 = If Bug 125137 were in place System: PIII 933 on Win2k Okay, Mozilla (Moz2) is still slower than IE on at least 3 of those images, which would indicate that improvement is needed, but not as much as one might have thought if they were at it unadjusted (first column) The fix in Bug 125137 would at least stop the CPU from hitting 99% (at least on my machine), and provide a more accurate display of the speed of the image, even if the image creator didn't realize s/he was creating an image that went so fast.

http://corp.pixel-industries.com/index2.html still has 100% cpu testing with 2002040903 on win-xp, 1.1.ghz, 327ram and making the mouse-cursor hog a bit every second.

minusing to topembed- and adding embed as per edt meeting, since this does not relate to a particular embedding customer.

> still has 100% cpu testing with 2002040903 On my K6-III/400 with 192MB ram, Win2K: 2002040803 uses 100% cpu power. While 2002040903 uses 35% and the ui is well responding. Definitely a huge improvement.

See also: http://dormcam.mine.nu:8080/orbitz.gif This is a single GIF image, yet while visible makes my computer unusable. (Athlon 1800, Moz 1.0 RC1)

Just tried http://dormcam.mine.nu:8080/orbitz.gif on trunk from late last week; I saw no problems. Please specify OS, memory, and also graphics card. Of others could verify (or not) it would be useful.

I see it on orbitz.gif with Dual Athlon XP 1700+, 1GB DDR266 ECC RAM, GeForce 2MX, Windows XP.

80% cpu usage for http://dormcam.mine.nu:8080/orbitz.gif. Mozilla is still responsive and usable. When minimizing that window, cpu usage drops to zero. Testbed is K6-III/400, 192MB ram, Voodoo 2000 graphics card, Win2K, Moz 2002041718. Video driver problem?

I forgot to mention Build 2002042008. BTW, it doesn't make my system unresponsive, just slows it down (I do have 2 CPUs after all) It also uses 90% of one of the CPUs. IE6 uses a negligible amount of CPU (<1%). Also, IE plays the animation much faster and smoother. This is irrelevant anyway. This is a known problem and new testcases like this don't give us anything we don't already know. It just adds spam when people argue over them (for no reason).

backing out of the patch in http://bugzilla.mozilla.org/attachment.cgi?id=79288&action=view (from Bug 135226) causes orbitz.gif to go from 40% CPU (with the patch) to 20% CPU (backed out of patch) on my Win2k PII-933. Same thing occurs on storm.gif (CPU usage doubled). If you aren't a source compiler, Build 2002041603 is before the offending patch, and Build 2002041710 contains the patch. You can confirm the CPU hike by trying the gifs on each of these builds.

10% CPU win2k pII-450 Mhz Building 2002041711 but with 1Gb Ram

Even though it's only ~19kb and 60x80, drives CPU to ~97% on a P3 550 with 192 megs RAM and Nvidia Riva TNT2 Pro 32 meg and Windows XP. Build 2002042403.

My CPU usage is at ZERO with that last GIF. Build 2002042608-trunk. Computer specs in comment 47.

Using trunk build 2002050608 on win-xp,1.1ghz,512 RAM I still have 100% cpu and a jumping mouse-cursor for example on http://corp.pixel-industries.com/generator/images/bt_background.gif http://corp.pixel-industries.com/generator/images/img_05.gif

Proposed relnote: Some animated GIFs, especially large ones, display slowly and make Mozilla somewhat unresponsive.

Increasing severity as this is affecting so many sites/portals.

site is down; adding image in case it never gets back up

Is this a Windows only problem? Using Mozilla 1.0 branch build 2002042705 for OS X, I just went through all the test cases that I could find in this bug and I did not encounter issues with any of them. I am running OS X 10.1.4 on a 350Mhz G3 tower with 256MB RAM.

Yeah, I see 99% CPU usage on Celeron 700 running on Windows 2000, but only 0.1% CPU usage on Pentium III 666 running on Linux. OS -> Windows

The pixel-industries site has moved to: http://www.pixel-empire.com/index2.html

build 2002051006 RC2 win2k, celeron 500, 128M RAM, Banshee 32MB I've been through all of the testcases here and I see no adverse effects with gif in focused window or in a tab. Average load while working is 8% and the most it went up to was 24%

Is this possibly a graphics card-specific issue? It seems like NVidia card owners are having more problems than others (unfortunately most of the people here didn't post their gfx card specs).

Using trunk build 2002052008 on win-xp, 1.1ghz, 512RAM, 32MB GeForce2 Go I have 100% and a jumping mouse-cursor. The major performance problems have already been enough confirmed.

Before the minimum frame rate delay patch was added, I believe this bug was more of an issue than now (see Comment #41, although it's information is a bit out-dated since they chose to go with 100ms delay) But we are still having some CPU problems. http://www.pixel-empire.com/index2.html currently uses 20% of my CPU for Win2k, PIII-933, nVidia VANTA 16 MB @ 1280x1024 @ 16bit color. In Opera, the same page with the same settings take 0%. In that particular case, I do not believe it's the video card's fault. However, if I change to 32bit mode, my CPU usage goes up to 50%. I blame nVidia for this, because my old video card (Matrox G200) had much less CPU change when changing the color depth. Either way, we should be striving to have better performance than other browsers, and if Opera/IE/some other browser is faster rendering (and rendering correctly), we should be trying to beat it. On a side note, changing the main URL to http://www.pixel-empire.com/index2.html sort of makes this a dup of 94828, since the page has multiple animated gifs. I much prefer using storm.gif (Attachment 47940 [details]) as the main test case for this bug.. which currently alternates between 10% & 18% CPU in Mozilla (specs above), and 0 on IE. I haven't determined why it alternates (sometimes when I load it, plays at 10%, sometimes at 18%, sometimes when I switch windows and back again, the CPU goes from one to another.. it's weird. At any rate, it should be 0%) RC2 build

*** Bug 99636 has been marked as a duplicate of this bug. ***

Sorry, that should be reversed.

Viewing this image by itself: http://www.cs.virginia.edu/~bts8f/v10.gif makes the mozilla window or tab that it is in extremely unresponsive. The task manager does not report any increased processor activity, and other mozilla windows and tabs respond ok. Machine information: Win2k, p4 2.2ghz, 512mb ram, geforce3 Ti200 running Moz 1.0rc3. Moz 1.0rc1 on a p3 450mhz, 128mb ram, ati rage pro running win98 does NOT have this problem.

Correction on Comment #67, the win98 machine that does not have the problem has 1.0rc2, not rc1.

That image (http://www.cs.virginia.edu/~bts8f/v10.gif) on my rc3 linux machine (p2 266) gives constant 77% CPU use. When I flip to another tab so that it's hidden, i get 63% CPU use. Expected: former much less, and the later zero

Win2K, 128mb RAM, P3 550Mhz, NVidia Riva TNT2 Model 64, Mozilla 1.0. Viewing http://www.cs.virginia.edu/~bts8f/v10.gif causes CPU to go to 100%, when switched to a non-focused tab, CPU goes down to 1%.

We use more because we generate masks and frame data on the fly, if I remember correctly. IE uses less, but with long anims IE uses progressively more CPU the longer the anim until it repeats, when CPU use drops back near 0.

When loading the "bt_background.gif" testcase, my CPU spiked as high as 98% at times and usage would fluctuate constantly. The mouse would become a Mexican jumping bean if I tried to move it - very unresponsive. And of course, after leaving the image, it sped up. Unresponsiveness definitely BAD... Mozilla 1.0 (2002053012) P4 1.8 GHz Windows XP Home NVidia GeForce-2 Consumer (Compaq) w/ 64 MB graphics RAM

*** Bug 124147 has been marked as a duplicate of this bug. ***

Platform->All OS->All

Don, might fixing bug 148598 have any affect on this?

possible dupe bug 155129

Re: comment #75 It seems to. The worst images are only using 70% or less now. But there are regressions on that patch that need to be addressed before we can count this as a win. Also, 70% is still terrible compared to ~0% that IE does.

The problem occurs also in newer builds (2002083005) on my Linux Box. The small gif on www.ish.com drives the resource usage up to 60% (Athlon 500). Is there already a solution around?

Topembed- as this is not currently blocking a major embedding customer.

*** Bug 155129 has been marked as a duplicate of this bug. ***

*** Bug 177911 has been marked as a duplicate of this bug. ***

*** Bug 178538 has been marked as a duplicate of this bug. ***

I'm not seeing this problem anymore, but I got an ATI graphics card (Radeon 9700 Pro). Is this bug fixed, or is it an NVidia issue? (Phoenix 20030218 Windows XP)

Aaron: The problem is most apparent with Nvidia cards. The URL for this bug brings my CPU to 100%, and the mouse is extremely jerky. Makes the computer almost unusable. This is with a Geforce 256 and Athlon XP 1800+

Same here with a GeForce 2 Go - also Mozilla's own viewer-demo ( resource:///res/samples/test10.html ) is causing 100% cpu usage. As someone currently working on that one?

CPU Usages from http://mozilla.animecity.nu/IMGTest/ 20030224 20030225 IE6 OP7 Storm 17.8 9.8 9.9 19.2 Storm No Frame Removal 17.5 9.8 53.5 19.3 Storm No Alpha 17.5 9.2 9.8 10.0 * PIII-933 nVidia Vanta, 1280x960x32b I'll be closing this bug in the next day or two if no one can find a _single_ animated GIF that uses high CPU on Mozilla, but not on IE or Opera.

The URL for this bug: http://bugzilla.mozilla.org/attachment.cgi?id=47940&action=view Mozilla 2003022508 uses about 55% CPU time and the mouse movement is very jerky IE 6 uses near 0% CPU time This is with a Geforce 256, using latest 41.09 drivers

The gif in comment #87, http://bugzilla.mozilla.org/attachment.cgi?id=47940&action=view gives 0% cpu usage with 2003022508 on my linux machine, Geforce3, with 3123 drivers.

Bug 105370 comment 2 has an animated GIF that still knocks Mozilla out. IE 6 displays it without a problem.

Try image Bug 105370 comment 2 locally and you'll probably find IE using more CPU and Mozilla (or at least I do). When it's loaded from the internet, Mozilla is slower than IE, due to something other then animation (such as decoding, or the networking code) It baffles me why WD is getting such high CPU usage.. I guess I will leave the bug open.

FWIW, the "no alpha" version of that animated GIF displays fine, with near zero CPU usage. It's the original one that makes my system sluggish.

I no longer see problems with either an ATI or a Matrox gfx card. 20030228/WinXP

This is weird. I am running win2k on a thinkpad with ati-rage mobility graphics card (m-agp) full hardware acceleration and am comparing this bug with bug 194627. On this machine mozilla (1.3b) uses roughly 20% of the cpu cycles (via windows task manager) however IE (6.0.28..) uses about 75% of the cpu cyles. I need to compare this to my desktop but was real surprised since most people see ie as being so much faster

*** Bug 196415 has been marked as a duplicate of this bug. ***

Here's one I came across today in Yahoo mail. It uses 100% CPU time and the mouse movement is so jerky that the system is nearly unusable when the image is on screen. Win2k 2003032604 Geforce 256

And I don't see a problem with my Radeon.

No problem with Mozilla 1.3 final under Mac OS X. Tried on various Mac systems with a variety of video cards.

Looks okay under Linux too.

Athlon 1.4Ghz, 512 Mb, Geforce2, Win XP, 1600x1200@32. I see ~60% CPU usage when the window with the picture is the viewable at the moment.

Perhaps we should consider closing this bug and focusing on bug 194627, unless somebody can find a testcase that doesn't require both Windows and an NVidia (or Matrox?) card.

Probably... If all of these testcases are pretty much specific to the Nvidia cards, then bug 194627 is probably the one

Notebook Siemens-Fujitsu Lifebook E-6624. iP933 512Kb cache, 256Mb, Ati Radeon Mobility M6. The CPU usage is about 45%.

10% CPU use here on Linux, but even when in a different tab. That's what tends to bog my system down... opening a few tabs, all with animated GIF ads on them.

anybody still seeing this? None of the test cases exhibit the symptoms for me anymore. Not sure if it's a change in mozilla or my updated nVidia drivers.

WFM too, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031113 Firebird/0.7+ (aebrahim) none of the images caused CPU usage % to go into double digits. AMD Duron 1.4, ATI drivers perhaps it was fixed by another bug?

Attachments here give 34, 7, 6, and 17 percent CPU use, respectively, on my P2/266. This seems reasonable. Note that the first image (as an example) still gives 23% if Firebird is minimized, and 13% if it is in another tab, but I believe there are other bugs filed for that issue. Also, the image I tested before in comment 69 has dropped from 77% CPU then, to 36% now. Unless this is going to be a tracking bug for more obscure animated image perf issues, this bug should probably be closed. All of the images attached and referenced now seem to have reasonable performance.

Can confirm as WFM on Linux-2.4.22 (Fedora Core1) Firebird 0.7 Bug 105370 comment 2 is still a problem, but that's a separate bug. Marking WFM. -M

Just to make sure, can anyone who hasn't got a Nvidia-card test these? http://www.gorgias.de/animgif/testcase_small.html http://www.gorgias.de/animgif/testcase_big.html For me CPU-usage is around 60% with one star visible and 100% with two on testcase_big. The small ones causes no trouble at all, CPU at 10-11%. Firebird/0.7+ 20031115, GeForce 3(latest drivers), AMD XP 1800

The testcases in the previous comment would be more appropriate for Bug 94828 since it has multiple GIFs (even though it's the same GIF). This bug it for slowness on a single animated GIF. But anyway, I get 65% CPU on IE 6 on the big test, and 99% on Mozilla 2003102404. Opera 7.21 sits at 50%

I get 0% in Firebird 20031030 with ATI Radeon 9800 on WinXP.

Got 30% load on Moz 1.4.1 on http://www.rp-online.de/public/article/journal/ausland/27138 (Ati Radeon Mobility)

Again on Moz 1.4.1 (SuSE 7.3, XFree 4.01, KDE 3.0.4, Athlon 500, Matrox Card) CPU usage up to 100% on gmx logout page http://www.gmx.net/de/cgi/logoutpage?CN=OKikuKCQr I dont feel that this is really 'resolved'

Axel: Provide an example of a single animated GIF that gives you 100% CPU usage

hmm, got 0-50% cpu on win2k with an Athlon XP2400+ with a current trunk nightly(even if the page is on a non-visible tab), you sure its that single anim gif tho ?

I looked at every of the four animated gif, each one separate does not give a high load. All together (maybe plus this scrolling thing) give me the high load. Also the attached examples on this bug have a max. of 5% total load.

So therefore, you're not seeing this bug. Perhaps bug 94828

Also, changing the browser identification and reloading http://www.gmx.net/de/cgi/logoutpage?CN=OKikuKCQr causes CPU load to drop from 95% (when mozilla is identified as Mozilla) to about 5% (when mozilla is identified to IE).

I suspect the performace issue on the page ArronM mentions is due to the javascript scrolling text towards the bottom of the page (easy to miss), and not the simple animated GIF. Perhaps the backend sends IE clients more efficient code.

This is not fixed yet. I still get 100% cpu usage with this: http://img154.imageshack.us/img154/8002/chibiassassinsig7vh.gif I'm using "Minefield" on pristine Fedora 8. I removed my .mozilla dir.

i confirm image on link above eats 50% cpu Mozilla/5.0 (X11; U; Linux i686; ru_RU; rv:1.9pre) Gecko/2008050604 Minefield/3.0pre

(In reply to comment #119) > I still get 100% cpu usage with this: > http://img154.imageshack.us/img154/8002/chibiassassinsig7vh.gif > > I'm using "Minefield" on pristine Fedora 8. I removed my .mozilla dir. On Ubuntu 8.04 and current trunk Minefield, remote X connection, this uses very little CPU (2-6%). I'll try it again later on a local display, but thus far this example doesn't show a problem. Jprof shows >75% of the time used is in Painting: 282 (77.7%) PresShell::Paint(nsIView*, nsIWidget*, nsRegion const&, nsIntRegion const&, int, int) 70992 1 (0.2%) 282 (77.6%) nsLayoutUtils::PaintFrame(nsRenderingContext*, nsIFrame*, nsRegion const&, unsigned int, unsigned int) 216 (59.5%) nsDisplayList::PaintRoot(nsDisplayListBuilder*, nsRenderingContext*, unsigned int) const 36 (9.9%) nsIFrame::BuildDisplayListForStackingContext(nsDisplayListBuilder*, nsRect const&, nsDisplayList*) 24 (6.6%) nsDisplayList::ComputeVisibilityForRoot(nsDisplayListBuilder*, nsRegion*) 2 (0.6%) nsDisplayList::DeleteAll()