Mozilla: 2002041709, but 0.9.9 also exibits this problem. OS: Debian GNU/Linux sid (i686), kernel 2.4.17, libc-2.2.4, gtk 1.2.10, XFree86 4.1.0 (1440x1080@24bit) HW: Athlon TB 1.0GHz, 768MB SDRAM (133MHz), 2.8GB swap, Matrox G400/32MB The scrolling performance was seriously degraded somewhere after 0.9.8. The page at the URL I listed is scrolling much slower with 0.9.9 and 1.0RC - I'd estimate about two to three times slower. Of course, it also happens with other loaded pages. Since this kind of a problem is inherently difficult to quantify, please bear with lack of hard data and my attempts at precise measurement. What I did: 1. Open terminal window and start "top". Set it to update every 1s (press "s", "1" and Enter). 2. On to mozilla. Visit the URL and wait for the page to load completely. 3. Click on the scroller's down arrow and keep it down. Observe top's display. With 0.9.9 and 1.0RC I observe between 0.9% to 5% of CPU for mozilla (peak 8%). More or less the same amount for Xserver. With 0.9.8, mozilla does not even register among top 20 CPU eating processes. X peaks at 2%. Another test: 1. Start top as above, set it do refresh every 2s (so it averages over longer periods of time). 2. Visit the same URL as above. 3. Grab the scrollbar and move it quickly up and down, making sure to arrive at the bottom of the page and back again. Repeat this motion constantly. This time 0.9.9 and 1.0RC show about 35-45% CPU for mozilla and the rest (55-65%) for X. Needless to say, CPU is maxed. With 0.9.8 I observe around 50% for mozilla and around 10% for X. There is still a lot of CPU time left. This recent "slowness" was also reported to me by some of my friends. I assign it to ImageLib, as I suspect some graphics related problem. If I am wrong, you know what to do. :)

Just tried 0.9.9 and 0.9.8 under Windows2K. The difference is not as big as under Linux, but still easily noticeable (visually).

I havn't made any changes to this code. tor?

Dup of bug 135626?

Well, bug #135626 seems to be Windows only. But this is true that this bug has something to do with backgrounds - I haven't noticed the problem on pages without them.

I am sure this is a background issue which I am addressing in 102321 *** This bug has been marked as a duplicate of 102321 ***

I've played more with windows version, observed bug #135626 there and I have to agree that the symptoms are identical, except for the pointer freeze, which does not happen in X. That may be some Windows peculiarity however.

This bug has been marked as a duplicate of bug #102321, but after reading comments there here it is obvious that it is caused by something else than changes to Windows code, as it it also happens on Linux (and is less severe). Also, it is present in 0.9.9, which was not the case for #102321. Reopening, as it still happens in 2002042808 (Linux/i686).

Status update: This page WFM on 2002050504 win32 on win2kpro.

Of course this page WFY and WFM as well. The point is, it WFM much slower than it did with Mozilla 0.9.8.

This should work now. A few things happened that it could be a tad slower for some, but faster for others. A palette image change made some pages alot slower for some (GFORCE II card users), that is now fixed. PatBlt was causing problems for some users, that is now taken out.. some some ( a few ) pages might be a tad slower.. but not alot. The progressive doubling algorithm is now used in a majority of cases (so some pages will get faster). Over all the product should be more robust especially on windows. If your seeing a small percentage decrease in speed.. you probably had a GForce card.. but it should be alot faster than it was last week. I dont think this should be an issue anylonger.

Things are still really bad using trunk build 2002050608 on win- xp,1.1ghz,512ram - cpu pegs to 100% and the mouse-cursor heavily jumps around.

This bug has a ton of animated GIF's.. I am betting that the slowness is caused by those GIF's.. which were recently changed to 24 bit internally, that means it takes a lot longer to change the values internally. I am duplicating this bug to 143046.. which addresses this issue. *** This bug has been marked as a duplicate of 143046 ***