Open Bug 202041 Opened 21 years ago Updated 2 years ago

Smooth scrolling is rate-limited

Categories

(Core :: Web Painting, defect, P5)

x86
Windows XP
defect

Tracking

()

People

(Reporter: vicslee, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401

I have an IBM Scrollpoint mouse --
   this mouse has a scrollstick instead of a scroll wheel - you control the rate
of scrolling by pushing on the stick harder

When I scroll with general.smoothscroll = false, I can scroll up and down the
page very fast if i push the button as hard as I can. With smoothscroll on, the
maximum scroll rate seems to be limited at a lower rate. I still want to use
smoothscroll, but i was wondering if the maximum rate could be raised, or a
setting placed somewhere for one to select a suitable maximum rate. Perhaps a
tick slider like the ubiquitous mouse speed one would be very helpful.

Reproducible: Always

Steps to Reproduce:
1. try to scroll as fast as you can normally
2. turn on general.smoothscroll
3. now try again.. I think this may affect normal scroll mouse users too

Actual Results:  
slower maximum scroll speed

Expected Results:  
faster scroll speed or user configurable would be even better
.
Assignee: asa → roc+moz
Component: Browser-General → Layout: View Rendering
QA Contact: asa → ian
Dainis, maybe you can help here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5
Victor, 

Before I start looking at problem can you please provide more information about
what mouse drivers are you using? Actually IBM ScrollPoint mouse = Logitech
ScrollPoint. I have one such mouse to verify - model 12J3619.

1. Are you using Logitech MouseWare suite (what version?) or there is some
specific software from IBM?

2. Is horizontal scrolling with stick working for you on Windows? I had not
chance to check this on WinXP - only OS/2. 
Looks to me that difference in scrolling speed is because the smooth scrolling
requires 10 (SMOOTH_SCROLL_FRAMES) times more screen redraws.

I will compile and send to Victor the gklayout.dll with SMOOTH_SCROLL_FRAMES set
to 4, so that he can verify that problem is really in the number of required
screen redraws.

We can implement some inverse function that will map the amount by which wheel
was scrolled into the number of scroll frames (or msecs per frame). The faster
you scroll the wheel (or bend the stick) the less frames we will need to animate
smooth scrolling.

BTW this should not be a problem with traditional wheel mice because in most
cases the reported scroll deltas (at protocol level) are in range +-4. Even if
the theoretical range is +-127 you have to try very hard to get values like 7 or
larger. On the other hand pointing devices with a stick (Logitech ScrollPoint or
Primax mouse) use the full range +-127.
> Looks to me that difference in scrolling speed is because the smooth scrolling
> requires 10 (SMOOTH_SCROLL_FRAMES) times more screen redraws.

Could be, but we don't actually do all those redraws. Try scrolling down in a
long document using the pagedown key. It should take almost exactly the same
time with or without smoothscroll off. When painting can't keep up, we just
increase the scroll speed and drop animation frames.
I verified that on Windows 2000. 
(PII 400 Mhz, ATI Radeon 85000, IBM ScrollPoint mouse, Logitech MouseWare 9.76)
My local build 2003041519 (without bug 198197 and bug 199024)

I have scrolled rather long page by:
1. Pressing Down
2. Pressing PageDn
3. With mouse stick bent to maximal position

I used stopwatch for timing. I've got the same scroll times whether smoothscroll
was enabled or not (82:0 sec, 3:0 sec, 8:90 sec). 
I have changed the SMOOTH_SCROLL_FRAMES from 10 to 4. The scroll times remained
the same.

So I was not able to reproduce the described problem on my machine. I've sent
the modified gklayout.dll to Victor for experiments. Most likely he needs to
check latest nightly, because since build 20030401 there were many smoothscroll
related checkins that possibly fixed that (Bug 199607 ?)

I would say RESOLVED-WORKSFORME
wow, you guys are fast... lots of comments to reply to here:
1. I'm not using the Logitech Mousesuite, just the Windows XP drivers
2. With this default driver, horizontal scroll does not work in any application 
- so you don't have to worry about that. 

Ya, I agree that the IBM ScrollPoint is the same as the Logitech one, my model 
is 12j3618, basically the same as yours.

I got the new gklayout.dll, but can't figure out where to put it..
That's probably not a problem - I see what you guys mean here, the scroll time 
for long documents is virtually the same with smoothscroll on or off.

However, when you're scrolling small documents that are around 1.5 times longer 
than the height of your screen, the decelleration applied at the end of the 
scrolls makes it sorta sluggish. I think it would be nice to have an option to 
either turn off that deceleration, or make it happen only on long documents. 

Also, I know you guys hate being compared to IE6, but since that's my main 
browser, I ran some tests there too. As far as I can see, there's no 
decelleration being applied there. I also ran some time trials. With the 1.4a 
release notes, the scroll time in mozilla for both options was about 3.7 
seconds. In IE6, that dropped down to  2.12 seconds.

Perhaps these two options would be helpful? (smarter decelleration/no 
decelleration, adjustable max scroll speed)

Thanks for all your work btw!
> the scroll time in mozilla for both options

You mean with smooth scrolling on and off?
ya, the time difference between scrolling for a long document isn't that big. 
But on small pages, since the scrolling never accelerates to maximum speed 
before decellerating, it feels a lot slower with smoothscrolling on.

A big difference in scroll time appears for long pages when being compared to 
IE however.
The difference in scroll time between us and IE is a completely different issue.
QA Contact: ian → layout.view-rendering
Component: Layout: View Rendering → Layout: Web Painting
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.