Scrolling using arrow buttons is twice as slow in trees

RESOLVED FIXED in mozilla0.9.1

Status

()

Core
XUL
P3
critical
RESOLVED FIXED
18 years ago
17 years ago

People

(Reporter: David Hyatt, Assigned: Brian Ryner (not reading))

Tracking

({perf, regression})

Trunk
mozilla0.9.1
x86
Windows 98
perf, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rtm-])

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
Nominating for rtm, since i suspect the fix will be easy.
Keywords: rtm
(Reporter)

Comment 2

18 years ago
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
(Reporter)

Updated

18 years ago
Keywords: regression

Comment 3

18 years ago
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

18 years ago
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

18 years ago
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

Comment 6

18 years ago
This has got to be a timer bug on win98. Do we have any engineers with win98 
boxes?
OS: other → Windows 98

Comment 7

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

Comment 8

18 years ago
Created attachment 17890 [details] [diff] [review]
Fix. Simple just uncomment move code.

Comment 9

18 years ago
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.

/be

Comment 12

18 years ago
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.
(Reporter)

Comment 13

18 years ago
? Why would this be the cause of the Win98 problem?

Comment 14

18 years ago
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]

Updated

18 years ago
Whiteboard: [rtm need info] → [rtm need info] fix in hand(??)

Comment 15

18 years ago
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]

Comment 16

18 years ago
Hyatt wants this one.
Assignee: evaughan → hyatt
(Reporter)

Comment 17

18 years ago
Minusing.  NO way I can get a Win98 environment ready in time to really deal
with this.
Status: NEW → ASSIGNED
Whiteboard: [rtm need info] → [rtm-]

Comment 18

18 years ago
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 → ---

Comment 19

17 years ago
->moz0.9/p3
Priority: P2 → P3
Target Milestone: --- → mozilla0.9

Comment 20

17 years ago
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

17 years ago
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

Comment 22

17 years ago
->bryner.  this should become much lower priority with new tree widget.
Assignee: hyatt → bryner
Status: ASSIGNED → NEW
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED

Updated

17 years ago
Keywords: perf
(Assignee)

Comment 23

17 years ago
How is scrolling performance on current builds?
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 24

17 years ago
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

17 years ago
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

17 years ago
> 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

17 years ago
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.
(Assignee)

Comment 28

17 years ago
I'm going to go ahead and mark this FIXED since performance is much improved in
outliner.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.