ESPN recently came up with a new page layout for espn articles. I included a link for one such article showing the new layout. When viewing the page, note the blue and black pixel border starting near the top, going across the screen and then forming a vertical border down the right hand side of the screen. I think they are using small image tiles that are repeated although someone who knows how to interpret this stuff will probably be able to figure out what exactly they are doing. The downside of this new page layout is that these little images are causing HUGE performance problems with mozilla. I'm running on a 1.5GHZ win2k box with todays (9/28) build. 1) Try making your window wider. Note the multi-second delay before we repaint 2) Try switching focus to another mozilla window and moving that window on top of the espn window. Note it takes a couple seconds before you can really start dragging the top level window over. 3) Try scrolling the page back and forth. Note it seems like the scrollbar is "fighting" you to scroll. The repaints appear to be keeping you from having a smooth scrolling experience. 4) Try changing the focus back and forth between the espn window and another window. Note the long delays before the window comes up to the front. It's very unforunate that ESPN changed their page layout to use these tiny tiling images just before we're about to ship a product. I hate to think what this performance behavior is going to be like on a more normal machine. =(

adding the perf keyword. Is there a top site keyword to add as well?

it's definetly the blue and black tile images they are using for the right hand border that's causing the problem. If I make the window wider so more tiling is exposed on the screen the performance degrades dramatically.

Build 2001-09-28-03 on Windows 98 SE (on a very old 200MHz Pentium Pro machine) I don't see any performance problem on this site.

I don't notice the performance problem either, 10-1 CVS build.

Hmmm. Still having problems on my 1.5GHZ machine using BUILD ID: 2001100103, win2k.

I have 10-22 cvs release build on WINNT and it loads quickly on 750Mhz machine with cable modem connection.

weird, my machine at home is a 450 MHz and I don't see the problem. I only see it here at work on my 1GHz machine. Well let's not waste time on this since it sounds like I may be the only one seeing this. Wanna mark this as WFM Marc? I won't be offended =).

OK, I tried my Mac (g4 500) and Linux (P3 500) and they are cool - marking WFM - no offense! ;) mscott, please just add a comment with your video HW info for later tracking - thanks. Also, does it improve if you disable image loading (I imagine it will).

*sigh* I don't know why this bug just plagues me. So I still see it on most of ESPN's websites which have those small background images. I fired up quantify and tried scrolling around one of the pages which is so slow for me. Turns out 97% of the time was spent in a windows routine called StretchDIBits. caused by 318 calls to nsImageWin::DrawTile. I'm going to re-open this bug now that I've done some analyis. However I don't think I should be bothering Marc with this bug. Quantify is clearly pointing at these little tile images as the culprit which has nothing to do with core layout functionality IMHO.

Marc, mind if I reassing this to Pavlov? The new URL I used under quantify was ESPN's baseball signing rumors page (although just about all the new pages they have show the problem): http://espn.go.com/mlb/mlbrumorcentral2001.html My test under quantify was starting at the top and scrolling half way down the page. The wider your browser window the more of these tile images you get and the slower we get when I scroll. Win2k, 1.5GHZ, nVidia GeForce2 GTS/GeForce2 Pro. True Color (32 bit), 1280 x 1024 pixels.

More spam....disabling image loading did not fix the problem because the the black and blue tiles are still downloaded even though the larger images on the page are not. over to pavlov for real this time. I meant to do it last time.

er, wasn't this going to be marked worksforme? looks fine for me over a modem on win2k. mscott: upgrade your video drivers (www.nvidia.com)

I have the latest drivers that came out on 12/03.

*shrug* maybe may patch for 104999 will fix this for you

On a hunch, I turned hardware acceleration (Display -> Settings -> Advanced -> Troubleshooting) down one notch. I made a simple testcase with that background (with width: 1600px so I can scroll horizontally) and a little text for vertical. I compared the speed of both horizontal and vertical scrolling with full acceleration, and one notch down from full. Maybe it's my imagination, but the lower acceleration seemed about twice as fast. It wasn't as jerky. It's hard to notice vertical, as it's pretty fast there, but horizontal scrolling jerks when you move the mouse quickly from side to side. Now let's take a look at this lower acceleration level's description: "Disable cursor and bitmap accelerations. Use this setting to correct problems with the mouse pointer, or to correct problems with corrupt images." Now, I know Mozilla stores images in video memory, and uses hardware blits to draw whenever possible. The way this is being done is probably inefficient for the hardware. The processor doesn't go through expensive state changes and all that. I figure horizontal scrolling is slower because even scrolling one pixel requires a paint command to redraw each tile. Vertical scrolling only has to repaint tiles that have newly moved onto the screen. Anyway, can anyone reproduce this speed difference between full acceleration and full-1? My system is: Win2k SP2, Celeron 500, 448MB RAM GeForce 1 SDR, 23.11 drivers, DirectX 8.1, 800x600 32 bit, maximized mozilla window.

Wow that's an incredible deduction. Turning my harward performance from the MAX down to about 1/2 way (disable all directdraw and direct3d accelerations) and the performance problem is completely gone. it scrolls faster than IE on the same page. Heck the entire browser is screaming now. I can't believe how fast espn pages are loading right now. This is bizzare. What made you think to try turning that down? Why is mozilla effected by that setting but not IE I wonder....

I've done some stuff with DirectX (in Visual Basic!). I've done some performance tuning. Video hardware is designed for the big stuff. It spends a considerable amount of time preparing a task, so when it comes time to do it, it gets done really fast. When the task is small, but the setup is still large, this can hurt performance. What's even worse is when you send a series of similar commands to the video card, and do the setup before each one even though you only need to do it once. So hardware acceleration was my first suspect. Actually, just now I checked out some code and found this: http://lxr.mozilla.org/seamonkey/source/gfx/src/nsRenderingContextImpl.cpp#161 // slow blitting, one tile at a time.... ( will create a mask and fall into code below -next task-) It falls back on slow code when there's an alpha channel. Remove that from the GIF, and it's blazing fast.

Any news on that? Bug 122996 seems to be related to this.

original URL appears to be fixed, 2002-2-21-03 w2k, probably bug 122996, also bug 98252 (in 0.9.8) has contributed to tiling and fixing several problems with scrolling. not seeing any slow scrolling anymore on many bugs. Please confirm, Thanks.

yeah, this was fixed between my changes and dcone's tiling changes

my bad, this bug is not actually fixed. Re-opening. I told Pav it was but I cranked up my hardware optimizations without rebooting. Now that I have restarted my machine this problem is back.

On what build and URL? What video card? The performance problem was fixed for me. Scrolling is nice and fast at that ESPN URL in both a nightly from a few days ago and the 0.9.9 release.

on the same test url I posted under the url field. Video card details are already listed under comment #10. Build ID: 2002030908.

Regression: Build 2002031803 is showing this performance problem, but 0.9.9 is not. (I retested 0.9.9)

This is a serious performance problem affecting many websites. It should probably be fixed for 1.0.

I agree. The new perf issue is definetly a regression. It was fixed for a while now ESPN is dog slow again. Can we look at re-triaging this?

major sites, nominating topembed.

over to dcone. he has been playing with the windows image tiling code recently. perhaps he can shed some light on this.

WFM: Scrolling is fine for me using cvs trunk 3/25 build on WinXP on 750Mhz athlon.

topembed+ till we confirm there is no problem here - triage team (chofmann, cathleen, marcia)

Kevin, did you follow the steps in the bug and crank up your video card's performance accelerators to the max? This bug happens on certain video cards. Are you using one of the ones that causes the problem? nVidia GeForce2 GTS/GeForce2 Pro. True Color (32 bit), 1280 x 1024 pixels. The problem goes away if I tone down my video accelerators by setting it to: disable all directdraw and direct3d accelerations

I can see some slowdown scrolling this page, its chunky but not unusable. The problem is the patBlt, seems video cards support this windows calls in different ways. My card at work for example.. wide, narrow tiles or very small tiles blit very fast, but slightly largers tiles that have the same width and height slow down. My card at home flies on all size tiles.. thats a GForce II card.. and I see no problems.On windows 98 and some drivers.. patBlt will crash the system and that is a know windows bug.. they say to solve by reinstalling the correct drivers. I have a bug open to fix all these problems by taking out this patBlt use the progressive doubling for our blits and cache the larger tiles that are created with the original nsImageWin object.

I can duplicate this on my laptop. The following page: http://www.tivo.com/discover/ displays horribly slow on my Dell laptop with the Nvidia GeForce 2Go video hardware (it pegs the CPU). Turning down the performance setting such that the hardware acceleration is disabled makes the page display like normal. Seems to be something with hardware acceleration on certain cards no?

I would totally agree with your results.... thats what I am seeing.

bug 133261 includes a patch which completely removes the calls to the gdi patblt on WIN32. This should also fix this bug. patblt seems to be unreliable. On some graphics cards its fast. On others its very slow (depending on the level of acceleration) The fix in bug 133261 uses progressive doubling of the tile into an offscreen tiling buffer to make the rendering of tiled images fast instead of relying on the gdi patblt call.

nsbeta1+.

Comment on attachment 80474 [details] [diff] [review] Patch to take out the PatBlt.. use progressive tiling most of the time. I think you want to change the value it used to determine if it needs to use the progressive doubling algorithm from 3 tiles to at lease 8 tiles. The overhead of progressively blitting the tiles to an offscreen then blitting it back to the window is probably higher than the cost of just blitting the 8 tiles to directly. // if alpha is less than 8,not printing, and not 8 bit palette image then we can do // a progressive tile and the tile is at least 4 times smaller than the area to update if ( (mAlphaDepth < 8) && (canRaster!=DT_RASPRINTER) && (256!=mNumPaletteColors) && (numTiles > 3) ) <== change this from 3 to 7 { I can notice a lag when scrolling http://members.optushome.com.au/clef/mozilla/pa/using but when I change it from 4 tiles to 8 tiles as the progressive doubling threshold the lag disappears. r=kmcclusk@netscape.com.

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

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

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

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

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

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

Some more URL's with background images which scroll slowly depending on the graphics card: http://www.aintitcool.com/ http://whirlpool.net.au/ http://members.optushome.com.au/clef/mozilla/pa/ http://www.central-soelden.at/menuehighlights.asp http://www.swva.net/

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

Comment on attachment 80474 [details] [diff] [review] Patch to take out the PatBlt.. use progressive tiling most of the time. sr=attinasi

adding adt1.0.0-. Please get this into the trunk and let's look at this for rtm.

fixed on the trunk..please test this since I dont have any of the graphics cards that cause this. I did some tests to make sure things dont slow down beyond what I have.. but I have not seen the really bad behavior. Thanks

Fixed for me. (GeForce2MX)

I have mixed results. http://www.aintitcool.com/ is fixed http://whirlpool.net.au/ is NOT fixed http://members.optushome.com.au/clef/mozilla/pa/ is NOT fixed I'm running build 2002042403. This should incorporate the changes right?

I need one additional thing for Phil's changes.. let me get that in today.. then retest Phil. The patch I put in did not fix the comment Kevin made about the size.. so that needs to get in for some of the larger backgrounds. Give me one more day (checkin).. and this should be fixed.

Re-open until I get that last little fix in.

Another site that is not fixed yet is http://www.devx.com/ Hopefully the new patch will fix it as well. Jake

Ok.. checked in.. now go ahead and re-check everthing next build you get. Thanks.

FYI: I tested all of the URL's in this page and all of the dups. The only one that is slow scrolling on my machine is http://www.devx.com/. Although my machine is not a very good test because I was not seeing the original slowdown due to the patblt performance issue with some cards. This at least shows that the new patch does not cause a slowdown for machines which were not seeing the original problem.

I could add that, in my rather aged system (K6-III/400, Voodoo 2000, Win2K/SP2), http://members.optushome.com.au/clef/mozilla/pa/ is still not scrolling smoothly (but it's usable). IE6 behaves extremely smoothly. Instead of making this bug a meta for image tiling performance problems, why don't we open a new performance bug for tiling performance on Win32?

Unfortunately, bad news. On the latest trunk nightly (2002042510), all 3 of the pages are back to being 100% CPU and slow. (aintitcool, whirlpool and clef/mozilla/pa/).

The latest 1.0 branch nightly still does not have this regression. Why can't we just back out the code that caused it on the trunk? Or is it more complicated than that?

Filed bug 140236 for the problems mentioned in comments #56, #57, #58 (and one more url).

I don't understand something.. The branch has the original regression in it. It was the build that had all the problems with the patBlt started on. So I took out the patBlt for the trunk.. and did a progressive doubling, now that is not as fast as a patBlt(on machines that support this), but it also does not exibit the bad behavior of patBlt on machines that dont support this. All this was done on my machines that I could not reproduce any slowness.. just on reporters comments. So now after I put in this fix.. your telling me that the branch (I am assuming the 1.0 branch) never had this problem. I started this work based on the problems the 1.0 branch was having, that I could never reproduce but I was told there was a problem. How slow is slow.. for you, is it un-usable.. or just a tad chuncky. The regression I am tryin to fix it the 1 to 2 seconds before it updates.. unusable.. not the .. it does not scroll as smoothly as IE.

This has always been my position. I filed a bug describing the TRUNK regression between 16-17 April. http://bugzilla.mozilla.org/show_bug.cgi?id=138948 Before this date, the scrolling all my listed pages (whirlpool, aintitcool, /clef/mozilla/pa and ben's blog http://www.silverstone.net.nz/weblog/) is SMOOTH. After that date, it is slow, and on the mozilla/pa one and ben's blog it is 1-2 seconds between screen updates (the others are less severe). Therefore, there is a checkin during that period that caused a severe regression on the trunk. The branch is still scrolling smoothly (last checked yesterday).

With my fixes in.. and no PatBlt. on my NT 4.0 400 mhz machine, my 1.5 ghz gforce II nvidia 64 meg w2k and my 300 mhz windows 98 AllinWonder.. I get good scrolling.. meaning, meaning it takes lets that a second to scroll from top to bottom. My 1.5 ghz is very smooth. My Nt 4.0 has a little chunkiness.. but not bad. My Windows 98 is very fast. Ok.. so if you are having a problem.. there are a few things you need to tell me. 1.) Web site, operating system, speed of computer. 2.) Speed of scroll. Unusable -- 2 second for each update. Hard -- 1 second updates. Chunky -- scrolls, but the scroll bar moves in chunks. average -- works.. very little chunky smooth -- scrolls smoothly.. can see any chunck movment. 3.) If you have a GForce II card.. what are your optimization settings. on my I have a Hardware Acceleration slider under trouble shooting. I can set this anywhere from 0 to 6. 6 is full acceleration. I dont get any difference at all. 4.) If you have a GForce II card.. try the same test with your settings for acceleration changed. What happens. 5.) Only do 3 or 4 if you are having extreem difficulties. I have tried on 4 different computers, and can not duplicate any of this extreem slowness. I have seen some chunky after I took out patBlt and did get extremly bad with patBlt on windows 98. But now.. all computers are usable.

Last thing.. if any of you having problems.. can do a build.. that would help alot.. I have some experiments I want to try using optimized bitmaps, like a one line change.. and we could see if we get any difference.

Open until I can figure out what is going on.

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

pulling off of the 1.0 RC2 list.

2002042606 (latest RC1), Win2K, GForce2 MX, Athlon 800, 512 MB RAM. nVidia drivers 28.32 (released 4/26) full acceleration. http://espn.go.com/mlb/news/2001/0927/1255952.html - chunky to hard http://members.optushome.com.au/clef/mozilla/pa/ - smooth http://www.tivo.com/discover/ - smooth http://www.aintitcool.com/ - smooth http://whirlpool.net.au/ - smooth http://www.swva.net/ - chunky to hard accel at -1 http://espn.go.com/mlb/news/2001/0927/1255952.html - average http://members.optushome.com.au/clef/mozilla/pa/ - smooth http://www.tivo.com/discover/ - average http://www.aintitcool.com/ - average http://whirlpool.net.au/ - smooth http://www.swva.net/ - average accel at -2: same as -1

Same as above, but with 2002042703 (latest trunk) full acceleration. http://espn.go.com/mlb/news/2001/0927/1255952.html - average http://members.optushome.com.au/clef/mozilla/pa/ - chunky http://www.tivo.com/discover/ - couldn't connect http://www.aintitcool.com/ - average http://whirlpool.net.au/ - couldn't connect http://www.swva.net/ - smooth accel at -1 http://espn.go.com/mlb/news/2001/0927/1255952.html - slightly chunky http://members.optushome.com.au/clef/mozilla/pa/ - slightly chunky http://www.tivo.com/discover/ - couldn't connect http://www.aintitcool.com/ - average to slightly chunky http://whirlpool.net.au/ - couldn't connect http://www.swva.net/ - average accel at -2: same as -1 All tests use the mouse wheel, since the arrow/scrollbar arrows don't move the page quickly enough to really tell one way or another. Also, went back to full accel, and the mozilla/pa/ test site was only average to slightly chunky. Tried again after reboot, and it went back to being chunky.

OK, I'm sick of this bug. It's affecting too many web pages (not least of which, my own!) Asa told me to make this a smoketest blocker.

how.. can this be a blocker.. thats totally not fair. I think I did the responsible thing opening this bug so everyone knows that its high on my radar.. being sick of this bug is not a reason to make it a blocker. It has not regressed.. at all. I reopened this until I could make sure that it did not regress..which it has not The branch may have the problem, although some cases might be faster.. there are cases that are ALOT slower..and unusable. The PatBlt that is in the branch causes problems on some graphics card.. thats a problem. The trunk does not have the patBlt.. which only gives us a chunky scroll at worst case.. this has been the way its been for about 2years. Only recently has the patBlt gone in.. and that caused a bunch of problems. From what I can tell.. with the new code.. we are at worst case.. chunky.. which is alot better than not usable like we were before. I am just trying to get a handle on what our problem is here. From what I can tell.. we have this situation.. 1.) PatBlt (not in this build)-- can cause problems on windows 95, 98 and on some GForce II cards (not the one I have). 2.) The optimization for nsImage that was turned off a while ago.. and not turned on for the background tile.. may be the culprit for chunky.. but at this moment I can not test this because I can not reproduce any of the cases on my machine. 3.) This bug seems to only happen on some machines.. non-of which I have.. but I keep on looking for more machines to test. I really dont think this is a smoketest blocker. Its something that has been happening on some pages for some time. I think that the worst cases have improved from not-usable to chunky. That is a good thing. I think I can improve the performance to smooth on all cases.. I just need a machine that I can get chunky scrolling, I can not find a machine like that I am removing that tag.. and if you think it deserves this tag please call me.. email. I think the fix we have is a good one.. and I would like to add 2 more things.. to improve the chuncky cases (very few). Optimize the bitmaps and some caching of the tiles. Until then.. this is plenty usable in my optionion.

Excellent news guys! I do not see slow scrolling anymore! Ben's blog, /clef/mozilla/pa, whirlpool.net.au, aintitcool.com are all much better (if only slightly slower than on the 17th April, but I imagine dcone's yet-to-come changes will fix that). Trunk Build 2002042808 shows the improvement. Build 2002042708 was still slow. My guess is dcone's checkin for bug 134887 did it. Thanks!

Argh I spoke too soon! I closed Mozilla, opened it again and the problem reappeared! I just tried turning down my hardware acceleration one notch and it went smooth again. I think this may have been mentioned previously in this bug though. Sorry for the spam all.

Guys, maybe there are two separate problems with tiled backgrounds? Some time ago I've filed bug #138034 about scrolling performance degradation. That bug was marked as a duplicate of this one, but after reading your comments here it is obvious that it is caused by something else, as it it also happens on Linux and is less severe. I'll reopen bug #138034 now, please take a look.

Can someone apply this small patch.. and see if it speeds up the slow test cases they might have. I can't test this because its a theory.. but it would be very helpful if someone could as soon as possible and report the results.

saari said he has some ideas on this.

dcone, I applied the patch and did not see any improvement (winxp, tnt2).

Went through the same sites as David Smith on a Athlon 1.2 Ghz, 256 MB, KyroII 64, Win2k(sp2) on build 2002042908. Here are my results: full acceleration. http://espn.go.com/mlb/news/2001/0927/1255952.html - chunky http://members.optushome.com.au/clef/mozilla/pa/ - hard to unusable http://www.tivo.com/discover/ - average http://www.aintitcool.com/ - chunky http://whirlpool.net.au/ - hard http://www.swva.net/ - smooth accel at -1 http://espn.go.com/mlb/news/2001/0927/1255952.html - average http://members.optushome.com.au/clef/mozilla/pa/ - average http://www.tivo.com/discover/ - average http://www.aintitcool.com/ - average http://whirlpool.net.au/ - chunky http://www.swva.net/ - smooth accel at -2: same as -1

Can someone apply this patch... see if things speed up. I would try but again I dont have a machine I can reproduce the problems.. so I am just trying things that might help.

Just to be on the safe side, this is a patch for the trunk that needs to go in that fixes some recent image performance regressions. I'm not certain this is related at all, but worth a check.

Saari, THAT'S IT! I applied your patch and the scrolling is SMOOTH (even smoother than with acceleration turned down a notch before). This fixes whirlpool.net.au, aintitcool.com and clef/mozilla/pa for me. Please try to get this on the trunk ASAP. What is the bug # for that patch? Thanks a lot! dcone: I applied your patch but Mozilla crashed on startup.

I had to clobber and build when I applied my patch.. because of the new members in the nsImageWin.h file. Anyway.. its good we found the problem.. seemed to be a palette problem.. and not an image tile problem. Great news. I still would like to get this caching in there... but the call to test this is no longer needed.

Also.. is this problem only in 256 color mode (8 bit)for a display.. or is this the product of the GIF's being dithered. Was everyone who had this problem using an 8 bit display?

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

this will affect everyone in every bit depth. Don, while we're here, you want to review the patch? Checking it in on this bug is as good as any IMO

Comment on attachment 81771 [details] [diff] [review] Another possible patch to try r=dcone

Comment on attachment 81771 [details] [diff] [review] Another possible patch to try sr=jag

->saari

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

fixed

petersen, could you please verify this fix so we can get adt checkin approval? thanks.

Verified on the May 22 trunk build (2002-05-22-08) under Windows ME.

verified

Verified on May 19th branch (2002-05-19-05)under Windows ME.

I found that my system has reacted very badly to the patch for this bug. I filed bug 149224 as a separate topic for investigation. Details there.

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