Tree scrolling using the up and down arrow buttons on the scrollbar has halved in speed on the branch and trunk. This happened at some point within the last couple of weeks. Moving the thumb slowly up and down still drags quickly, which leads me to believe that something is going wrong with the timers on Win32. Either they were deliberately changed to be a larger time (BAD IDEA!), or there's some regression. In either case, the tree is now scrolling way too slowly.

Nominating for rtm, since i suspect the fix will be easy.

Whoa. On further examination, its happening in Web pages too. The scrollbar "jerks" and moves way slower than the normal OS speed. This is observed on Win98. Changing summary and component.

Scrollbars in web pages jerk when you first pull them because the system has to load the background images. Try this in classic and you will notice it does not happen. As for arrow scrolling. Not sure. Could someone have changed the timer increment?

So here are some numbers: Summary: 1) Scrollbarbutton in _trees_ is way behind on win98 (timers?) 2) HTML scrolling is much slower, primarily due to lines-scrolled (?) It's also why scrolling is apparently faster in IE relative to Nav4. 3) We may have slowed down in tree-scrolling recently as well, because an earlier test in threadPane on win2k had us almost even (now we trail by about 20% from Nav4) win2k box is 500MHz 128MB HP Kayak XAs 1024x1280 Elsa Gloria 16bit win98 box is ?500MHz 128MB dell prec. 210 1024x1280 nvidia riva tnt2 32bit (e.g. nominally equal, except for color depth -- but the win98 is generally faster for Nav4.x operations) ---------------------------------------------------------------------- Scrolling down the page http://www.mozilla.org/xpfe/xptoolkit/xbl.html -- an HTML page with no images or forms, but does have tables, links, etc. -- sidebar is closed, and the content area has the same size for IE5, Nav4 and Mozilla. The font-size is as close to the same in each browser as I can make it -- nominally 16px/12pt. scrollbarbutton Nav 4.73 10-16-08-MN6 10-16-08-MTrunk IE5(**) win2k 22s 36s 36s 8s win98 20s 33s 32s 8s arrow keys Nav 4.73 10-16-08-MN6 10-16-08-MTrunk IE5(**) win2k 15s 24s 24s 6s win98 14s 23s 22s 6s ** IE5 scrolls about 4 lines per arrow keypress or scrollbarbutton event which is why it appears so much faster (but with a loss of fine-grained movement in the document). Nav4.x scrolls ~1.5 to 2 lines per event, which again increases the effective rate of scrolling. Dragging the thumb in IE5, Nav4 and Mozilla is the "same speed", but there is no objective way (that I know of) to measure this. ---------------------------------------------------------------------- Scrolling in a threadPane for a 500 message IMAP folder -- same number of visible message in the threadpane, set up in normal threepane setup (15 visible rows) scrollbarbutton Nav 4.73 10-16-08-MN6 10-16-08-MTrunk IE5 win2k 32s 37s 40s n/a win98 28s 51s 52s n/a arrow keys Nav 4.73 10-16-08-MN6 10-16-08-MTrunk IE5 win2k 24s 23s 25s n/a win98 21s 25s 24s n/a IE5 n/a -- I didn't think this was particularly of interest, but I could install OE and try this out if you want. I will check Linux and Mac in a while.

Sol says marketing would highly value a significant speedup here, but the fix would have to be very simple/safe to have any chance of landing for N6. This is lower priority than any stability/broken feature bugs. rtm need info

This has got to be a timer bug on win98. Do we have any engineers with win98 boxes?

I doubt it, but we have plenty of spare machines that could run Win98...

This needs to get a r= and a sr= pretty damn quickly.

Removoing RTM NEED INFO, adding FIX IN HAND PDT attention please

I nominate buster, waterson, and hyatt as reviewers. /be

This patch appears to be identical to the patch in bug 57026, which is already r= and sr=. The only problem is that it appears to be causing a crash on one of the regression tests. I'll look at that today.

? Why would this be the cause of the Win98 problem?

I think that attachment was made erroneously (it occurred at the exact same time that it was attached to the other bug). (On another note, removing "[rtm need info]" and replacing it with "fix in hand" will do the complete opposite of attracting PDT attention, and would even drop this bug off of evaughan's own queries. I'm putting back '[rtm need info]', but I'll leave 'fix in hand' until Eric can comment).

Yep somehow bugzilla attached this patch to the wrong bug could be user error don't know. I DO NOT have a fix for this. I do not have a win98 machine and have no ideas why this might happen.

Hyatt wants this one.

Minusing. NO way I can get a Win98 environment ready in time to really deal with this.

This bug is entered "2000-10-14 17:38" and has been marked M10. Removing invalid target milestone, sorry for the spam.

->moz0.9/p3

Note that bug 60986 is filed separately to cover the issue of "how many lines to scroll per click in an HTML document." This bug is only for the case of scrolling behaviour in XUL <tree>s.

updating summary.

->bryner. this should become much lower priority with new tree widget.

How is scrolling performance on current builds?

Still pretty slow using today's mozilla bits using win98 on my P2/366 laptop. I measured 68 seconds to scroll through 650 messages using the scroll button, 40 seconds using the down arrow key (although the thumb didn't update at all during the that scroll). With 4.7, it took 35 seconds and 32 seconds, respectively, both correctly updating the thumb all the way down.

Repeating the same test from 10/16 (but not with IE): Scrolling in a threadPane for a 500 message IMAP folder (Modern skin). -- same number of visible message in the threadpane, set up in normal threepane setup (15 visible rows) scrollbarbutton Nav 4.7x 03-26-14 win2k 32s 32s win98 28s 28s arrow keys Nav 4.7x 10-16-08-MN6 win2k 25s 27s win98 42s 43s Comparing to 10/16, I have no idea what's up with the arrow keys number for win98 with either Nav4.7 or mojo. Either I was on crack in October, or something major changed on that machine or Nav4.x version [it's now 4.75, was 4.73]. But, aside from that, my times don't show any marked difference between mojo and Nav4.x. I don't know why Peter's numbers are so different. With the scrollbarbutton, this is just click and hold till done, right?

> I don't know why Peter's numbers are so different. Now, I do ... with Classic skin on Win98 scrollbarbutton Nav 4.7x 03-26-14 win98 28s 42s <--** was 28 in modern! arrow keys Nav 4.7x 10-16-08-MN6 win98 42s 43s

Yup, click and hold til done, using Classic. I also made the thread pane the full height of my screen (48 rows), which no doubt takes longer to scroll. After switching to Modern, and restarting (since it crashed), it took 72 seconds to scroll using the scrollbar down arrow, 46 seconds via cursor-down. Odd that Modern seems faster for you, but slower for me.

I'm going to go ahead and mark this FIXED since performance is much improved in outliner.