Add animation to vertical wheel scrolling for smoother experience.

[gokaysatir]

Change-Id: I5c6cce08f68ec6ac99ac668bb78c12274ce72f3e

• Resolves: #
• Target version: master

Summary

TODO

• ...

Checklist

• I have run make prettier-write and formatted the code.
• All commits have Change-Id
• I have run tests with make check
• I have issued make run and manually verified that everything looks okay
• Documentation (manuals or wiki) has been updated or is not required

[mmeeks]

This may be smoother - if so good, but it 'feels' awful with a touchpad - I can't control where I'm scrolling to at all it seems - all fine control is lost :-) please re-test and re-work for touchpad.

[eszkadev]

It works much worse with laptop trackpad with this change. Previously it was smooth

[mmeeks]

It works much worse with laptop trackpad with this change. Previously it was smooth

That's not my experience - I think there has been significant scope for improvement here for a good while.

[Cwiiis]

Without this patch, my experience is that trackpad scrolling is smooth and wheel-scrolling is instant (but has a jerky appearance as it's scrolling a large area at once). With this patch, trackpad scrolling is broken (hard to describe exactly, will go into more detail below) and wheel scrolling is smoother, but not as smooth as I'd expect (i.e. <60Hz), at least in Writer.

Trackpad scrolling is broken because onMouseWheel will always animate, regardless of the magnitude or frequency of the wheel events - so in the case of a trackpad, you very frequently[1] receive events of small magnitude. Each event stops and resets the last animation and so it only ever scrolls a tiny fraction of a tiny amount until it stops receiving events.

I'm not sure why scrollwheel scrolling isn't smooth, I would need to profile - it should be driven by requestAnimationFrame and so it not hitting the screen refresh tells me it's doing too much work.

There are two problems:
1- We need to distinguish between wheel events and trackpad events. The latter need to perform scrolling directly, as they did prior to this patch. The bad news is there isn't a reliable way to do this (well, there is in Firefox and possible in some backends of WebKit, but that's not all that useful).
2- When an animation is interrupted, we need to sensibly take into account the old destination and adjust the new destination accordingly. You shouldn't be able to scroll faster prior to this patch, essentially.

Solving the second problem would make trackpad scrolling work, but feel a bit laggy compared to fixing the first. When a wheel event is received while a previous scroll is still animating, I would suggest altering the animation parameters so that the first animation is extended to end at the sum of the two deltas. The new animation's start velocity needs to match its current velocity for it not to feel weird.

For the first problem, in Firefox, wheel events have deltaMode[2] property set to LINE. This isn't the case in Chrome it seems, unfortunately, so you need a heuristic. My suggestion would be any wheel event less than half a line height received in quick succession of another (where quick = a screen refresh) deactivating animation until no more events are received for a few frames (let's say 50ms).

My more left-field suggestion would be to structure things so that we can take advantage of the browser's native scrolling support, which will be correct per platform and take away a bunch of maintenance burden - but given how things are organised now, this wouldn't be simple and is a more long-term thing.

[1] the browser should throttle this at the screen refresh, but I don't know that this is always true for all browsers. In many years past in engines I don't remember, this would sometimes just be the refresh of the device - which can be many times the screen refresh...
[2] https://developer.mozilla.org/en-US/docs/Web/API/WheelEvent/deltaMode