100% cpu usage on all parts of the site. no problems in ie p3 744, 512mb, tnt2

WFM, current CVS, Linux. Reporter: Please always include build ID in bug-reports.

-> GFX (?) and confirming with win2k build 20020531.. (Athlon 1.2Ghz) The scrolling is slow...

Possibly a dupe of bug 133261.

WFM with build 2002052306 under Windows ME. I can't see any slow scrolling. Reporter, please try a newer build.

winxp build 2002060108

winxp build 2002060108 while loading scrolling is smooth

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

-> dcone. WFM: Using 6/7/2002 branch build on WinXP. Is scrolls smoothly.

It might scroll smoothly for most people if they have power house machines, but anyting with a 1Ghz and lower will notice it.

Please try this again with the newest trunk build.. I put a fix in there that should clear this up.. I would think. Also.. this is not a powerhouse cpu issue.. there are some graphics cards thats have a problems with some types of blits.. so we are in the process of fine tuning how this works. For example the machine I work on.. is 400 mhz.. and it scrolls just fine.

I hope I got the right build because I don't notice a difference. Build ID: 2002061008, I'll try again tomorrow.

what build did you try that test on.

i have been trying it on nightly builds for weeks and 1.0 winxp, current build 2002061208 p3 744; 512mb; geforce4 (just upgraded from tnt2)

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

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

I can confirm the slow scrolling of the testcase. 1600*1200, duron 900, 512Mb, GeForce2 MX 32Mb, Win XP.

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

Tryed with different resolution's and color depth - still slow. But with 16 bit it's faster than with 32 bit.

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

Build: 2002061408 on Win2000, Cel466, Matrox G400 The slow scrolling is caused by the insane background image of e.g. 10x8000 pixels. Normal images of that size also cause degradation in scrolling performance. Below 3 more links, the first 2 having a huge background image, the 3rd having a huge normal image. http://magma.nationalgeographic.com/ngm/data/2001/10/01/html/ft_20011001.2.html http://www.sausagetools.com/professional/overview.html http://www.splendorofflorence.com/LearningCenter/philadelphia.htm

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

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

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

here is the URL from the dupe http://www.go-mono.com/class-status-System.html

Another slow scroller is about:config (build 2002061408) although I think this is another problem than the insanse background problem.

Please retest your urls.. I have put in fixes for some other GIF problems and scrolling seems to be much better on those.. it has fixed at least two choppy scrolling bugs.

I still experience 'choppy' scrolling, for my system, on http://bugzilla.mozilla.org/attachment.cgi?id=86381&action=view from http://bugzilla.mozilla.org/show_bug.cgi?id=149224 using the 07/10 trunk build.

build 2002071108; winxp still choppy

btw: when visiting http://www.go-mono.com/class-status-System.html with the latest trunk build 2002071508 on win-xp pro I still crash. ---- // // Watchdog Event Log File // LogType: Watchdog Created: 2002-07-16 13:59:25 TimeZone: -60 - W. Europe Standard Time WindowsVersion: XP EventType: 0xEA - Thread Stuck in Device Driver // // The driver for the display device got stuck in an infinite loop. This // usually indicates a problem with the device itself or with the device // driver programming the hardware incorrectly. Please check with your // display device vendor for any driver updates. // ShutdownCount: 317 Shutdown: 0 EventCount: 12 BreakCount: 12 BugcheckTriggered: 1 DebuggerNotPresent: 1 DriverName: nv4_disp EventFlag: 1 DeviceClass: Display DeviceDescription: NVIDIA GeForce2 Go (Dell Mobile) HardwareID: PCI\VEN_10DE&DEV_0112&SUBSYS_00E51028&REV_B2 Manufacturer: NVIDIA DriverFixedFileInfo: FEEF04BD 00010000 0006000D 000A06E0 0006000D 000A06E0 0000003F 00000008 00040004 00000003 00000004 00000000 00000000 DriverCompanyName: NVIDIA Corporation DriverFileDescription: NVIDIA Compatible Windows 2000 Display driver, Version 17.60 DriverFileVersion: 6.13.10.1760 DriverInternalName: nv_disp.dll DriverLegalCopyright: (c) NVIDIA Corporation. All rights reserved. DriverOriginalFilename: nv_disp.dll DriverProductName: NVIDIA Compatible Windows 2000 Display driver, Version 17.60 DriverProductVersion: 6.13.10.1760 --- This has been mentioned in bug 152992. Is there a need to reopen or file a sperate bug?

I can get very slow scrolling if I am in 256 color mode, but not if I am in millions of colors (every test case scrolls very smoothly). But you have to restart the app in 256 color mode to duplicate the problem. Is this what everyone is seeing? If that is the case.. I do know what causes that, its the blitting of 32 bit images to a 8 bit screen.. which requires a huge amount of lookup which we have to fix.

Testing for example http://magma.nationalgeographic.com/ngm/data/2001/10/01/html/ft_20011001.2.html http://www.sausagetools.com/professional/overview.html http://www.splendorofflorence.com/LearningCenter/philadelphia.htm with trunk build 2002071608 on win-xp pro,1.1ghz,512ram,GeForce2 Go (32ram) @32bit scrolls really choppy!

Specifically responding for my situation, and bug 149224, I am using "32 bit" video, with an Elsa Gloria Synergy Permedia video card with 8MB of vram. The drivers are the most current available afaik (and I updated them within the past two months).

I have coppy scrolling with all urls listed. 32bit color 1280x1024 winxp. latested build. geforce 4(64mb)

Found a big problem.. we were painting the entire background everytime.. may have been clipped.. but still cost alot.. to do that large of a blit.

it would be great if anyone would apply this patch and see if the performance goes up on the test cases for you.. and/or if you see any problems.. its a very very simple patch to one file.. and 3 lines are changed. This could solve all these background slowness problems.

dcone: Nice! This patch (in a current trunk build win32) completely fixes the problem I noted in bug 149224, attachment 86381 [details]. Good stuff.

1) anyone else have a chance to try out this patch? 2) dcone: is this a possibility for 1.1final?

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

transferring keywords

Comment on attachment 92750 [details] [diff] [review] this is the correct patch. r=rods

Comment on attachment 92750 [details] [diff] [review] this is the correct patch. sr=kin@netscape.com

Comment on attachment 92750 [details] [diff] [review] this is the correct patch. a=asa (on behalf of drivers) for checkin to 1.1

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

checked into the trunk. Fixed.

this fix causes problems with the main toolbar & scrollbar graphics in modern.

I backed out my changes.. I dont get those problems at all. I will investigate what is going on.

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

Without respect to the downsides, this really improved scrolling for me on the National Geographic page. XP, matrox g450, 512mb, 2002072908 trunk.

I also saw the regression and reported it as bug 159985. I suggest leaving 159985 open for today to reduce the number of dups and marking it as fixed tomorrow.

I'd been running with the earlier version of this fix (attachment 92239 [details] [diff] [review]) for several days, and had no problems. But, yeah, with attachment 92750 [details] [diff] [review], I also see the drawing errors reported here and elsewhere.

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

Is it just me or is there no functional difference on Windows between attachment 92239 [review] and attachment 92750 [details] [diff] [review]?

I'd like to thank Dean for pointing out that I am an idiot, and if I'd looked at the point in context, I would have seen that there is no functional difference between those two patches. And, I also missed the effect that this patch had on Modern scrollbars (I rarely use Modern) and on <select> drop markers in html form controls. The patch does indeed fix the scrolling problem, but I really botched it when I missed those other issues. Sorry.

This patch fixes the scroll bar problem in the modern skins. Again I ran all my test cases but this time under modern skin also. Please test with this for a while. This patch takes the intersection of the tile rect and dirty rect like we do for linux, but it also calculates the correct offset.

Your indentation seems a little wacky in that last patch.

I found some small glitches with the last patch.. namely that the scroll bars were missing there little horizontal lines. This patch uses the Linux logic.. and seem to set everything correctly. The last patches assumed a more straighforward use of the offset.. apparently there can be some strange offsets generated. This patch has passed all my test so far.. I will keep testing. Please apply this and give any feedback.. I think this is important because if fixes a ton of performance problems.

Comment on attachment 93289 [details] [diff] [review] Best patch. r=peterl

Comment on attachment 93289 [details] [diff] [review] Best patch. sr=kin@netscape.com You can move the xOffset and yOffset declaration into the |if| block if that's the only place they are used.

This also seems to fix the slow painting and scrolling on the apges on http://www.directv.com. I see r= and sr=, can we push this in, or are we still waiting for something else here (other than approval)?

Er, s/apges/pages/

Comment on attachment 93289 [details] [diff] [review] Best patch. a=asa (on behalf of drivers) for checkin to 1.1

Please also add to the branch whenever possible since there are partners affected. Thanks.

it seems for me that patch contains \r\n pairs ...and i met problem applying it on non-Win32 system

what was the problem.. it xplatform code.. actually. Did the patch not apply, or did once applied.. it did not compile?

I understand.. sounds like you need to set that option on patch in order to work... I use the posix setting to get things working correctly.

bug 160103 came and went, seemingly corresponding to the first checkin / backout of this fix. So this URL may be worth testing: http://www.w3.org/TR/REC-html40/interact/forms.html

Comment on attachment 93289 [details] [diff] [review] Best patch. marking r=peterl can't this be checked in now?

checked into the trunk. Fixed.

ver fixed on build id 2002080108 on win xp

Build 2002080119, Win2K, Matrox G400 Just noticed a new redrawing problem. It think it is caused by the path for this bug. Reproduce: 1. Open http://www.tweakers.net and maximize your window 2. Open a new window in front of the browser and move it like a maniac over the Mozilla window (must have show while dragging on). You will see the black background on the right side sometimes turn light gray. Can anyone confirm this and should a new bug be opened or not? After all, the patch itself may be correct, this can be another bug in Moz.

Backed out changes.. seems there are some inconsitent ways we use the backgrounds.. and some assumtions we make. I have to study this some more.

Test case to check against for the next patch. http://www.angelfire.com/space/jlariviere/

Just an additional note about the test webpage: Under the Select Styles... you can click on a link to change the page style. Also, (I think it's related to your changes...) if you change the style enough times it causes mozilla to crash everytime (I'm clicking a link every 2-3 seconds). I'll double check tomorrow with the build with the changes backed out that it does not still happen.

This screenshot is 080208 on Windows 2000. I have been using the build all day and I've only seen the problem once in Navigator and once in Mail. I don't know how to reproduce this problem. This isn't horrible corruption like with the build from several days ago; it's just a background color showing through where the background image should appear.

http://www.thekompany.com/home/ that I tested with. I found the problem... there was an offset variable used in nsImageWin::DrawTile for the alpha (depth of 8 bits) that was not right. The offset was always 0 when nsCSSRendering::PaintBackgroundWithSC called this routine. When I changed it to the new way the offset passed in would not always be 0 and this offset was used incorrectly for alpha. I fixed it. I will post the patch.

Passes all my current tests. These test include the past and also the more recent tests that caused the problems.

Comment on attachment 94332 [details] [diff] [review] Slightly cleaned up version of last patch. r=rods

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

Patch seems to work fine. Solves the National Geograpic site and seems to solve some DHTML performance bugs (at least bug 157401), but the saucagetools and splendorofflorance.com (see comment #21) are still somewhat slow here (Cel 466, Matrox G400). Will the patch make it into 1.1?

nsbeta1+.

A bug that I tested with the newest patch.. putting it here for documentation about the pages that are tested with the patches. http://bugzilla.mozilla.org/show_bug.cgi?id=160664

Comment on attachment 94332 [details] [diff] [review] Slightly cleaned up version of last patch. With your changes, it looks like you can replace all references to ScaledTileHeight_Offset and ScaledTileWidth_Offset with ScaledTileHeight and ScaledTileWidth. sr=kin@netscape.com with that change.

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

I found a new problem.. a PNG did not scroll correctly, the offsets were all messed up. It was because of the reverse order of the bitmap and how the offsets were passed in. I reversed how I went through the bitmap to be in sync with the tiles and offsets passed in. IT Fixed that bug and I tested with all my test cases and the URLS put in this bug report. All check out great.

Comment on attachment 95279 [details] [diff] [review] New Patch. r=kmcclusk@netscape.com

Comment on attachment 95279 [details] [diff] [review] New Patch. sr=kin@netscape.com

sorry for the spam dcone, when can we expect a check-in? I have not downloaded a nightly build since the very first check-in and its killing me :)

Fixed. Scrolling should be 100% faster.

I was hoping that the fix for this would fix the scrolling bug at http://www.meyerweb.com/eric/css/edge/ , but it doesn't. Notice the Astronaut in the background. Try scrolling and watch the astronaut get chopped up in to little pieces. Is this something that should have been addressed by this bug, or is it another issue? Note that to really reproduce this, you should make the horizontal size of the browser pretty small and then scroll up and down. You will notice that either the part of the astronat that goes offscreen disapears or is stretched out into little pieces. Resizing the browser window snaps the image back to its original form. Jake

http://www.exactaudiocopy.de is still choppy on scrolling and mouse-over of left menu-items are not very responsive (really very slow). Using trunk build 2002081908 on win-xp pro,1.1ghz,512ram,GeForce2 Go (32MB).

in answer to comment #95 : scrolling is smooth (using mouse wheel / cursor key), with trunk build 2002081904 - WinXP Maybe my Athlon XP1800+ / 512 Mo / GF4 Mx is way to fast ? ;-)

Try draging the scrollbar up & down (quite fast). What about the very slow responding mouseovers on the menu-items on the left side?

In answer to comment #97 : no problem at all, there seems to be blocked in a frame on the left side, so no refresh problem at all !

Build 2002081908 on win95 (I know, don't tell me, it's not mine) http://www.exactaudiocopy.de is here also very slow. It is caused by the 3 huge background images in the <td> tags. The background image is 1200x1400. Removing the image makes it scroll fast. Even scrolling the image itself ( http://www.exactaudiocopy.de/cell_bck.gif ) is slow here. Suggesting to reopen this bug.

Another data point on the site http://www.exactaudiocopy.de: scrolling using keyboard, mouse and scrollbar all seem smooth and fast for me (though the throbber is continuous). 2002081904 on XP, Athlon 1.2ghz, 512mb, Matrox g450. So far, this seems like wonderful work, dcone!

I checked out http://www.exactaudiocopy.de/ on my PIII 450 with 384meg RAM and a 3dfx Voodoo3 with 16meg RAM. Scrolling is not perfectly smooth, but completely acceptable. Totally usable. However, the mouseovers on the left side unacceptably slow. I checked on IE5.5 on the same machine and scrolling is smooth (slightly more so than Mozilla) and the mouseovers are *way* faster than Mozilla. This patch definitely provided an improvement, but there is still some more work to be done. Plus, don't forget about comment 94 where there is still some foo with the background image being chopped up. Jake

A few things I want to bring out. 1.) As far as the urls I tested and this bug addresses, I think I have fixed a major scrolling bug. Now if you have scrolling or hoovering issues I think you need to show how that relates to this bug (a regression, minimal speed increase, etc) so this bug will stay on track. If you can not show a relationship then a new bug needs to be opened and some research into what may cause this problem. My tests show at least 3 to 4 times speed increase with the URL's listed in this bug. If you have a site that is not fast at scrolling.. please indicate how that relates to this bug and if the fix here had any impact. 2.) If you open a bug about scrolling.. a comment like.. not very fast.. is not good enough. Please try to quantify the speed problem. 3.) Any regressions need to be addressed in this bug.. thats very important. But if you have a bug that is not a regression and were hoping this may fix it but did not.. open a new bug. 4.) Other issues.. like a hoover.. please open a new bug or find a bug that is already open and list the issue there. 5.) There are probably a bunch of issues that come close to this bug.. but if your comment is.. this url does not scroll fast.. it would help alot if the comment was more like .. this fix did not improve the speed of this url, more along the lines of how your comment relates to the fix. I think comments added should relate to this bug and the fix I put in. If you read the bug and the patch you will see that a huge issue was addressed.. and I appreciate all the help. I just want the bug to stay on track and comments to relate directly to this fix and the urls that were used to find, test and re-test this (the regressions caused by the fix).

Though the performance is now much better, I see a terrible regression on http://www.swva.net/ Mousing over the links creates a floating box which causes the background to not repaint properly. Also, moving another window over the background causes the same effect-- incorrect/no repainting.

comment #94 is something else. This problem existed in 1.1a. If not already filed, this should be made another bug, though it looks a lot like the PNG compositing problems that were fixed several months ago.

don't now whether this is of any value but: I can reproduce the original bug (slow scrolling)on the site www.sysinternals.com (using: Mozilla 1.0.0 Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.0.0) Gecko/20020530) reason: (as already determined) a large background gif image with the size of 1600 x 1 pixel. now, if I change the background image to 128 x 1 pixel or below, the scrolling is fast and smooth. I'm not a software programmer, but doesn't *128* ring a bell?

tloehnert@web.de, you need to download the latest nightly build from ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/ to test this bug. AFAIK, this is not patched for Mozilla 1.0 yet. When you download a nightly build, try testing the site then and you will notice that it is fixed.

Reopened for the regressions found. I found a png problem and also the problem found in comment 103. I have a patch to be posted shortly.

Patch fixes the PNG update problem ( offsets were not calculated correclty for updates) and progressive doubling problem ( the buffer size was to small). Also did some basic cleanup of those two routines.

Comment on attachment 96676 [details] [diff] [review] Patch to fix update problems. r=rods

Comment on attachment 96676 [details] [diff] [review] Patch to fix update problems. sr=kin@netscape.com

fixed problems with new patch.. all checked in.

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

Verifying this old problem is not occuring in the (2003-06-11-08) Win32 trunk or (2003-06-11-05) win32 branch. Tested under Win XP.