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.

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?

Huh, could well be.

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.

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

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.

May require that appshell favors interactivity over perf while handling mousewheel.

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.

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 http://www.aftonbladet.se/ using pixel scrolling, but it does seem more obvious.

I don't know if this would be the same bug or not but VERY noticeable scrolling lag on reddit.com comments. Example page: http://www.reddit.com/r/funny/comments/71fb6/the_creepiest_cat_ever/

(In reply to comment #17) > I don't know if this would be the same bug or not but VERY noticeable scrolling > lag on reddit.com comments. Example page: > http://www.reddit.com/r/funny/comments/71fb6/the_creepiest_cat_ever/ 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.)

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.

Cool.