56683 - Scrolling using arrow buttons is twice as slow in trees

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[David Hyatt]

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.

Comment 1

[David Hyatt]

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

Comment 2

[David Hyatt]

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.

Comment 3

[Eric Vaughan]

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?

Comment 4

[John Morrison]

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.

Comment 5

[Peter Trudelle]

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 

Comment 6

[Eric Vaughan]

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

Comment 7

[Peter Trudelle]

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

Comment 8

[Eric Vaughan]

Attachment: Fix. Simple just uncomment move code.

Comment 9

[Jason Eager]

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

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 11

[Brendan Eich [:brendan]]

I nominate buster, waterson, and hyatt as reviewers.

/be

Comment 12

[Chris Waterson]

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.

Comment 13

[David Hyatt]

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

Comment 14

[John Morrison]

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).

Comment 15

[Eric Vaughan]

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.

Comment 16

[Eric Vaughan]

Hyatt wants this one.

Comment 17

[David Hyatt]

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

Comment 18

[Péter Bajusz]

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

Comment 19

[Peter Trudelle]

->moz0.9/p3

Comment 20

[John Morrison]

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.

Comment 21

[Peter Trudelle]

updating summary.

Comment 22

[Peter Trudelle]

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

Comment 23

[Brian Ryner (not reading)]

How is scrolling performance on current builds?

Comment 24

[Peter Trudelle]

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.

Comment 25

[John Morrison]

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?

Comment 26

[John Morrison]

> 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      

Comment 27

[Peter Trudelle]

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.

Comment 28

[Brian Ryner (not reading)]

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