Tested on today's build on the Mac (WinNT doesn't show the problem). - Go to the Tinderbox page - Click the down arrow of the vertical scrollbar and wait until you scroll to the bottom of the page ==> It takes about 18 seconds on a G4/450 - Turn off GFXScrollBars in the Debug prefs - Repeat the test above ==> It takes about 5.5 seconds (more than 3 times faster)

assigning to evaughan as p3 for m15.

*** This bug has been marked as a duplicate of 24956 ***

Reopening. Bug 24956 describes a difference of speed between Moz and Nav4x on all platforms while this bug (31131) describes a difference of speed between GFX and Native scrollbars on the Mac. I tested on Windows: it scrolls at the same speed with and without GFX scrollbars. On the Mac, if it wasn't for the scrollbars, this bug shows that Moz could scroll 3 times faster but then even we we fix it, we may very well still scroll twice as slow as Nav, as described in bug 24956.

*** This bug has been marked as a duplicate of 29840 ***

Reopening again. This is not about a difference of speed between Moz and Nav. It is about a difference of speed between Moz-with-native-scrollbars and Moz-with- GFX scrollbars on the Mac. It is a platform-specific problem. We know that on all platforms Moz is much slower than Nav, as described in bug 24956, bug 29840 (which are dups, I believe) and maybe other ones too. The present bug shows that native scrollbars, on the Mac only, cause an additional and serious slowdown. Paint Flashing in the Debug prefs may give an idea of what's going on. Eric- If you don't do Mac, you may have to reassign to a volunteer in the Mac team (pink, beard, sfraser).

Mass-moving most M15 bugs to M16

See also bug 33602. Never paid attention before but I believe 33602 might be a dup of this one as symptoms described in it diminish/disappear with Gfx scrollbars turned off.

Nothing to do with 33602 but as evaughan wrote, this is indeed a dup of bug 29640. Scrolling is slower with gfx scrollbars because nsScrollbarButtonFrame::MouseClicked() sets the nsXULAtoms::curpos attribute, which causes a reflow (while with native scrollbars, we just send a NS_SCROLLBAR_LINE_NEXT message to the scrollview and everything's fine). I'm reassigning this bug to myself to investigate the Mac specific part: why is the reflow so much slower on the Mac than on Windows?

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

Copying this comment in from 29840 because this bug is where this comment really belongs. Adding lordpixel to cc: list. ------- Additional Comments From lordpixel@mac.com 2000-04-27 18:04 ------- In a sense this comment is just noise, but I have to say this is probably my number one issue with GFX scrollbars on the Mac. They're slow as molasses on a G4 400MHz so I can only imagine what they're like on a slow machine (unless its purely a throttling issue). This is with view manager 2. Switching back to native scrollbars cures the problem.

taking it over. I have a fix for slow gfx-scrolling and page loading by picking apart the non- rectangular update region and not using it as a bounding box, but sending multiple paint events for each small rect. scrolling is now _MUCH_ faster, as are page loads since we no longer redraw the entire previous page before loading the next one.

This really stops me from using the Mac product, also nominating for nsbeta2 so we can get a [mm/dd] window for checkin.

Pink: I don't know what the RepeatService is for but are you sure you want on platforms other than the Mac to have a REPEAT_DELAY much longer than the INITAL_REPEAT_DELAY? It used to be the opposite.

my bad, you're right. i'll fix that. thanks pierre!

accepting to avoid those silly reminder messages from terry.

[nsbeta2+][6/15]

[dogfood-]

file this one to netscape.public.mozilla.slow.mac.builds.die.die.die fixed.

verifying scrolling test on tinderbox page took 12 secs without gfx scrollbars it took 8 secs with gfx scrollbars