Closed Bug 418351 Opened 14 years ago Closed 13 years ago

scrolling tinderbox using 2-finger scrolling is much slower than with scrollbar


(Core :: Widget: Cocoa, defect, P3)






(Reporter: vlad, Assigned: jaas)



(Keywords: perf)

When viewing the tinderbox Firefox waterfall, if you grab the horizontal scrollbar you can move it around as quickly as you want.  However, if you use two-finger scrolling to move it left and right, it lags behind quite a bit and feels very sluggish.  Same thing with the vertical scrollbar.  IMO we need to look into this -- mac laptop users are going to be 2-finger scrolling all over the place, and it looks like we should be able to make that experience significantly better.
Flags: blocking1.9?
Playing around with this some more, it almost looks like we're scrolling too far -- if you make some short jerky motions left or right, the scrolling often seems to keep going way beyond what I would expect.  There may be something we can tweak here?
Is this something other than the fact we don't support pixel scrolling (bug 350471) and are therefore forced to always send line-scrolls?
blocking1.9- since this is not labelled as a regression and it is late in the game, would certainly be nice to have a fix though.
Flags: wanted1.9+
Flags: blocking1.9?
Flags: blocking1.9-
Flags: wanted1.9+ → wanted1.9.0.x+
Priority: -- → P3
Duplicate of this bug: 427955
Just to clarify:

- Scrolling too far / jerky motion is bug 350471 (pixel scrolling).

  (We're not really scrolling too far; touchpad scrolling uses
  acceleration, but since the scroll steps are so large, it doesn't feel right.)

- Delayed / slow / laggy scrolling is something completely different - in fact,
  it will become worse as soon as we support pixel scrolling because we'll
  receive more scroll events.

The problem is that we're repainting immediately after every scroll event. As soon as scroll events come in faster than we can keep up rendering, we lag behind.
The solution would be to only repaint after all pending scroll events have been processed. Processing a single scroll event would then only involve updating the target scroll position and maybe initiating a new smooth scroll function, but no repainting.

Compositor (bug 374980) will probably solve this problem; it schedules "immediate" repaints using a 0-interval timer which is only executed after all pending events have been processed.
(At least that's my understanding of it - please correct me if I'm wrong.)
Depends on: compositor
It might fix this, but it might not. It would certainly make this easier to fix since it will make scrolling asynchronous so we would then be able to implement a policy for how frequently we repaint due to scrolling.
Could we handle mousescroll asynchronously? Would it help at all?
ESM could create a nsRunnable which would then scroll the relevant scrollable view.
Duplicate of this bug: 456420
May require that appshell favors interactivity over perf while handling
Also, worth to check if we really need ForceViewUpdate always after
mousescroll (called in nsEventStateManager::DoScrollText)
Getting rid of ForceViewUpdate is definitely worth a try.
Depends on: 457864
Duplicate of this bug: 458554
Re Comment 7:
> it will become worse as soon as we support pixel scrolling because we'll
> receive more scroll events.

It doesn't last noticeably longer on using pixel
scrolling, but it does seem more obvious.
Depends on: 459319
No longer depends on: 459319
I don't know if this would be the same bug or not but VERY noticeable scrolling lag on comments.  Example page:
(In reply to comment #17)
> I don't know if this would be the same bug or not but VERY noticeable scrolling
> lag on comments.  Example page:

That's bug 428070.
Bug 457864 helped a lot. Scrolling is pretty speedy on tbox.
(And for scroll page up/down 3 finger swipe is great.)
Depends on: 463958, 428070
Btw, is this still a problem with the latest trunk builds?
Scrolling tbox is fast here.
Seems a lot faster and smoother here.
Seems fantastic now. Lag is gone and it's just as (or almost as) smooth and fast as latest Safari.
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b2
Flags: wanted1.9.0.x+
Keywords: perf
You need to log in before you can comment on or make changes to this bug.