Closed Bug 56683 Opened 24 years ago Closed 24 years ago

Scrolling using arrow buttons is twice as slow in trees


(Core :: XUL, defect, P3)

Windows 98





(Reporter: hyatt, Assigned: bryner)


(Keywords: perf, regression, Whiteboard: [rtm-])


(1 file)

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.
Keywords: rtm
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.
Severity: normal → critical
Component: XP Toolkit/Widgets: Trees → XP Toolkit/Widgets
Priority: P3 → P2
Summary: Tree scrolling using arrow buttons is twice as slow → Scrolling using arrow buttons is twice as slow in trees and web pages
Keywords: regression
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

As for arrow scrolling. Not sure. Could someone have changed the timer increment?
So here are some numbers:


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

           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)

           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 
Whiteboard: [rtm need info]
Target Milestone: --- → M10
This has got to be a timer bug on win98. Do we have any engineers with win98 
OS: other → Windows 98
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
Whiteboard: [rtm need info] → fix in hand
I nominate buster, waterson, and hyatt as reviewers.

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).
Whiteboard: fix in hand → [rtm need info]
Whiteboard: [rtm need info] → [rtm need info] fix in hand(??)
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.
Whiteboard: [rtm need info] fix in hand(??) → [rtm need info]
Hyatt wants this one.
Assignee: evaughan → hyatt
Minusing.  NO way I can get a Win98 environment ready in time to really deal
with this.
Whiteboard: [rtm need info] → [rtm-]
This bug is entered "2000-10-14 17:38" and has been marked M10.
Removing invalid target milestone, sorry for the spam.
Target Milestone: M10 → ---
Priority: P2 → P3
Target Milestone: --- → mozilla0.9
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.
Summary: Scrolling using arrow buttons is twice as slow in trees and web pages → Scrolling using arrow buttons is twice as slow in trees
->bryner.  this should become much lower priority with new tree widget.
Assignee: hyatt → bryner
Keywords: perf
How is scrolling performance on current builds?
Target Milestone: mozilla0.9 → mozilla0.9.1
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)

           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
             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
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.