Scrolling using the scrollbar at http://www.dynamism.com/index.shtml is... fast in firebird 0.6.1 fast in firebird 0729 fast in firebird 0807 \ | regression happened in here slow in firebird 0809 / slow in firebird 0816 Test testcase shows that the problem is the huge background image. Originally reported by Kitsunebi at http://forums.mozillazine.org/viewtopic.php?p=156256#156256.

Just to confirm that this is not Firebird specific, scrolling is also slow with Mozilla 8/15-15 under XP.

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

This is a good example: http://www.design4online.com/blog/index.asp Mook mentioned a quick fix: Enter this in the address bar after going there, and press enter. Scrolling works fine again. <a href="http://forums.mozillazine.org/viewtopic.php?t=22591">here</a> that putting the code below completely heals the problem. javascript:alert(document.body.background="");void(0);

Is this Windows only? Did Linux regress at the same time or not?

Sorry for spam, but isn't this bug a duplicate of 124150?

To cause this bug, image height must be >= 1582 or image width must be >= 1601. Any image with smaller dimensions does not cause this effect. I’d say the severity of this bug should be increased – it makes Mozilla almost unusable on Celeron 1100 MHz running win2k and on AMD XP 2000+ it’s very noticeable. Also, not only is scrolling slow but also selecting text is very slow (lags) and hovering over links that have hover attribute set via CSS is also very slow.

Gert, is it the image *area* that matters, or is it just if the width > 1601 no matter what the area is?

Also, CCing tor since this is most likely a GFX/image issue

This is due to the stopgap checkin for bug 205893, which turned off optimization of images on the win32 platform.

alright then, I'll assign it to you and you can figure out what to do with it :-)

Reassigning to jdunn, who did the temporary patch.

This bug seems to dramatically affect the performance of sites like http://quadrone.org and even my own blog (http://weblogs.mozillazine.org/djst/). Gert, none of those sites use images with the dimensions you mentioned. The dimensions for http://weblogs.mozillazine.org/djst/images/back2.png is 700x1000, yet the performance is much worse now compared to e.g. Firebird 0.6. Blocking 1.5?

Forget I said anything about image dimensions – came back from weekend, tried again and now the critical dimensions seem to have changed! Small images still don’t cause slowdown but now image 1500x1500 will… I didn’t try to pin down the exact values. 700x1000 pixel image still doesn’t cause slowdown for me though. I tested it by making simple html page and then just changed background image pixel dimensions and kept reloading.

darin, can you help on this one? not sure if jdunn is back in action...

chofmann, sure i'll take a look once i get a win32 build env setup. btw, this doesn't seem to be performing badly under linux [firebird-trunk-2003-09-07].

Gert, my blog uses "background-attachment: fixed". Maybe that's the reason for the huge slowdown? If so, is there another bug filed for that? Fwiw though, the performance in recent nightlies is much slower than in Firebird 0.6, so something has definitely happened since then.

The good thing is that we now know at least one case where using GDI's is helpful. Some initial thoughts (and just thoughts...) -create GDI's for images larger than SOME_SPECIFIC_SIZE, otherwise use the current scheme -use GDI's for backgrounds (and maybe any image that we do compositing on (i.e. I wonder if alpha blended images also cause a slowdown). This way, nsImageWin doesn't have to be smart but the layout engine is the one that calls nsImageWin::Optimize I need to run some tests (with & without the fix for bug 205893) to see the problem for myself. Darin, thoughts? And yeah btw, the original patch causing the regression was only on windows. The original problem, is still an issue on Linux (since we never fixed it there.

as a quick fix, i think we should just make "someone" (either nsImageWin or imagelib) enable GDI for large images. then we can go back and do something fancy.

ok, this simplistic patch makes it so that we _will_ optimize images larger than 128k (that's 128Kb at 24 bpp). worst case, i think the number of GDI objects will remain reasonable. consider 32Mb of GDI objects in the memory cache... worse case is 256 HBITMAPS (256 * 128Kb = 32Mb). i think that should be reasonable. now, if someone has 1Gb+ of RAM, we might start getting into trouble. perhaps, we should also limit the browser's memory cache to some hard fixed limit, instead of letting it grow unbounded in size (albeit at a logarithmic rate) as the amount of system memory increases.

-> me

Comment on attachment 131109 [details] [diff] [review] v1 patch I am going to ok this, but note I have no review authority.

simon and pav may have opinions on this...

Comment on attachment 131109 [details] [diff] [review] v1 patch Well, this is certainly better than the previous patch that should never have gone in to the tree... The Win95/98 checks are important and something I had in my original windows image code.. perhaps they didn't get ported back when I reverted to the nsImageWin code. r=pavlov

Comment on attachment 131109 [details] [diff] [review] v1 patch requesting drivers approval for 1.5 final. i don't think we should ship 1.5 without this patch.

Comment on attachment 131109 [details] [diff] [review] v1 patch a=chofmann for 1.5... lets spin off another bug for redesign work...

fixed-on-trunk

ok, see bug 218861 for redesign work.

scrolling is definitely a lot faster in testcase. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030910 Firebird/0.6.1+

I'm not sure what the status is of 1.4.1, but this is a serious regression in 1.4.1 from 1.4. I've seen it come up twice in the newsgroups/forums from people testing the RC build.

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

answer to comment 20 from Darin Fisher: the 1Gb+ of RAM case isn't a problem, because Win9X doesn't support that much RAM. I also want to say that I was using (self compiled) Mozilla builds with the previous patch for two months, and I cannot reproduce the problem reported in this bug - all the test cases work fine for me (on 98 SE) with my old build and with new 1.4.1rc Mozilla. This bug has probably to to with the model of the graphics card used (i have a Nvidia card).

1GB of RAM is an issue on 9x, as it does support that much ram, but there is a bug in the VCACHE driver which causes it to take up address space equivalent to the whole physical memory. If left to its own devices, it takes up a whole GB of kernel address space, leaving none for the rest of the OS. If VCACHE is manually set to a sensible size in SYSTEM.INI, 9x can handle 1GB of RAM. See knowledge base article Q253912 for more details.

Is this page effected by the same bug: http://www.simplygirly.net/ or is it a different bug? Feels very slow in 1.5

Robert: no, that's bug 90198. This bug was fixed.

Jesse: Thanks. Wasn't sure if it was something related to this or not.