Problem | 问题背景
Right now, with smooth scrolling enabled, scrolling is still somewhat choppy in the steady and slow regime. This is evident in the attached photo, where each notch on the scroll wheel triggers a smooth but independent response, leading to a "jump" at the end of each response. Turning up the smoothing duration does not solve the problem, because it prolongs the braking at the end of the continuous scrolling, leading to a less crisp feel.
Proposed Solution | 期望方案
The desired behavior is that scrolling velocity remains as constant as possible during a long, steady, but slow scroll and drops quickly once the scrolling stops. I don't know what kind of data the scroll wheel sends to the computer. If there is a way to get high-resolution data from the scroll wheel, then we don't need any of this and I'd love to know how to do it. But if it's just a $$\pm 1$$ every time I scroll past a notch (about 15 degrees), then smoothness would have to come from software (which is precisely what MoS is doing). During a slow scroll, where the time between notches is on par or longer than a smoothed response calculated by MoS, scrolling still feels choppy as described above.
One possible solution is to implement a "history-aware animation" that is triggered above some minimum scrolling velocity (because you still want independent animations for truly independent, 1-notch microscrolls). It would look at past scrolling events up to some time limit (say ~200 ms) and predict the animation for some future time (~200 ms). If there has been a steady notch train (let's say uniformly one notch every 100 ms), then MoS should send a constant velocity corresponding to the one notch every 100 ms instead of a superposition of independent animations for each notch, which is choppy. If the notch train has been rapidly slowing down (let's say a notch was expected but not sent), that means the user has stopped scrolling and MoS should send a rapidly decreasing velocity.
The fundamental limit of smoothness from this solution is that the duration of deceleration at the end of a long scroll is limited by the scrolling velocity. In other words, you can only decelerate as fast as you scroll. The time it takes to decelerate must be larger than the period of the notch train, otherwise we don't have enough notch train resolution to predict whether the user has truly stopped scrolling on a timescale less than the period of the notch train. But this deterioration should be gradual rather than sudden if the algorithm is designed well, so one wouldn't suddenly feel a "failure" threshold at some scrolling speed. This change could be very beneficial for common use cases, let's say 10 notches/second scrolling, which is a velocity where the current implementation still has a significantly choppy feel.
Scope | 范围
Problem | 问题背景
Right now, with smooth scrolling enabled, scrolling is still somewhat choppy in the steady and slow regime. This is evident in the attached photo, where each notch on the scroll wheel triggers a smooth but independent response, leading to a "jump" at the end of each response. Turning up the smoothing duration does not solve the problem, because it prolongs the braking at the end of the continuous scrolling, leading to a less crisp feel.
Proposed Solution | 期望方案
The desired behavior is that scrolling velocity remains as constant as possible during a long, steady, but slow scroll and drops quickly once the scrolling stops. I don't know what kind of data the scroll wheel sends to the computer. If there is a way to get high-resolution data from the scroll wheel, then we don't need any of this and I'd love to know how to do it. But if it's just a$$\pm 1$$ every time I scroll past a notch (about 15 degrees), then smoothness would have to come from software (which is precisely what MoS is doing). During a slow scroll, where the time between notches is on par or longer than a smoothed response calculated by MoS, scrolling still feels choppy as described above.
One possible solution is to implement a "history-aware animation" that is triggered above some minimum scrolling velocity (because you still want independent animations for truly independent, 1-notch microscrolls). It would look at past scrolling events up to some time limit (say ~200 ms) and predict the animation for some future time (~200 ms). If there has been a steady notch train (let's say uniformly one notch every 100 ms), then MoS should send a constant velocity corresponding to the one notch every 100 ms instead of a superposition of independent animations for each notch, which is choppy. If the notch train has been rapidly slowing down (let's say a notch was expected but not sent), that means the user has stopped scrolling and MoS should send a rapidly decreasing velocity.
The fundamental limit of smoothness from this solution is that the duration of deceleration at the end of a long scroll is limited by the scrolling velocity. In other words, you can only decelerate as fast as you scroll. The time it takes to decelerate must be larger than the period of the notch train, otherwise we don't have enough notch train resolution to predict whether the user has truly stopped scrolling on a timescale less than the period of the notch train. But this deterioration should be gradual rather than sudden if the algorithm is designed well, so one wouldn't suddenly feel a "failure" threshold at some scrolling speed. This change could be very beneficial for common use cases, let's say 10 notches/second scrolling, which is a velocity where the current implementation still has a significantly choppy feel.
Scope | 范围