Closed Bug 86319 Opened 19 years ago Closed 17 years ago

(large) animated GIF has terrible performance


(Core Graveyard :: Image: Painting, defect, P3, major)


(Not tracked)



(Reporter: megabyte, Assigned: pavlov)




(6 keywords, Whiteboard: [adt3])


(4 files)

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 (??))
Keywords: perf
Here's another image which is not dimensionally large, but is about 200k in
filesize.  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.
Target Milestone: --- → mozilla1.0
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')

dupe of bug 82278 ?
Check out the url i supplied:
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%
OS: Windows 2000 → All
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.

On my linux machine, with xfree86 4.1, top reports the following stats:

 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:

 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. 
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
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

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
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.

marking regression per Aleksander's comments.. must be somewhere between 6/14
and 6/17 (notice original posting date)
Keywords: regression
Blocks: 104166
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 
Target Milestone: mozilla1.0 → mozilla1.0.1
*** 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 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 :-(.
Keywords: mozilla0.9.9
Blocks: 119597
*** 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. ***
Summary: large animated GIF has terrible performance → (large) animated GIF has terrible performance
another one bringing mozilla down - http://corp.pixel-
Blocks: 94828
Blocks: 94828
Some numbers of a K6-III/400, 192MB, Win98 system, with 2002022308: : 100% cpu
usage, even when if the animated part is not visible (window minimized or
animated part out of window boundaries).  : 50%,
about 5% when minimized. : 15%, less than 4
% when minimized.
_basic, I think it would be better if you attach those gifs in bugzilla. : 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%.
Keywords: mozilla1.0+
*** Bug 130503 has been marked as a duplicate of this bug. ***
*** Bug 124999 has been marked as a duplicate of this bug. ***
migrating keywords
Keywords: nsbeta1nsbeta1-
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. does not exist anymore

------> Moz |Moz2 |Moz3 | _IE 
------> 98% | 10% | 34% | 20% | 318x240; 11 Frames @ 10ms delay
------> 99% | 70% | 99% | 24% | 600x900; 3 Frames @ 20ms delay
------> 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)
------> ~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.
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.
Keywords: topembedembed, topembed-
> 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:

This is a single GIF image, yet while visible makes my computer unusable.
(Athlon 1800, Moz 1.0 RC1)
Just tried 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 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 (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.
Component: ImageLib → Image: GFX
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
Depends on: slowGIF
Proposed relnote: Some animated GIFs, especially large ones, display slowly and
make Mozilla somewhat unresponsive.
Keywords: relnote
Increasing severity as this is affecting so many sites/portals.
Severity: normal → major
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
OS: All → Windows 2000
The pixel-industries site has moved to:
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. 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
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. ***
Blocks: 71668
Blocks: 147938
Sorry, that should be reversed.
No longer blocks: 147938
Viewing this image by itself:
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 ( 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.
causes CPU to go to 100%, when switched to a non-focused tab, CPU goes down to 1%.
Depends on: 148637
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
Keywords: mozilla1.1
*** Bug 124147 has been marked as a duplicate of this bug. ***
OS: Windows 2000 → All
Hardware: PC → All
Don, might fixing bug 148598 have any affect on this?
Keywords: nsbeta1-nsbeta1
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.
Keywords: perfmozilla1.2
The problem occurs also in newer builds (2002083005) on my Linux Box. The small
gif on drives the resource usage up to 60% (Athlon 500). Is there
already a solution around?
Keywords: topembed-topembed
Topembed- as this is not currently blocking a major embedding customer.
Priority: -- → P3
Whiteboard: [adt3]
Target Milestone: mozilla1.0.1 → mozilla1.2beta
*** Bug 155129 has been marked as a duplicate of this bug. ***
*** Bug 177911 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.2mozilla1.4
*** 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+
Depends on: 194627
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
                    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:

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
Flags: blocking1.4a?
The gif in comment #87,

gives 0% cpu usage with 2003022508 on my linux machine, Geforce3, with 3123 
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. ***
Flags: blocking1.4a? → blocking1.4a-
Attached image Large animated GIF
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.
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.

Closed: 17 years ago
Resolution: --- → WORKSFORME
Just to make sure, can anyone who hasn't got a Nvidia-card test these?

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
(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
I dont feel that this is really 'resolved'
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 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.
Keywords: relnote
This is not fixed yet.

I still get 100% cpu usage with this:

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
Product: Core → Core Graveyard
(In reply to comment #119)
> I still get 100% cpu usage with this:
> 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()
You need to log in before you can comment on or make changes to this bug.