Debounces scroll events in web viewer. #5208
Conversation
|
When reviewing / trying this, you should note that even a timeout of 4ms (which is the minimum timeout by spec) improves the responsiveness. I think 250 is an ok value, but would love to get feedback about your experience. |
|
Can we cancel previous scheduled timeouts for the case when user rapidly scrolls? At least if two are already scheduled, last one. |
|
I just pushed a version where I cancel all scrolls except the last one. Because of that I needed to choose a much lower timeout. |
|
maybe add requestAnimationFrame polyfill (https://gist.github.com/paulirish/1579671) and use that as well? |
|
When scrolling a bit rapidly, pages appear to be empty for a longer time, which in my opinion is worse than the 250 ms version. |
|
i agree. |
|
we don't need rely on rAF in this case -- its only useful when we ready to paint. |
|
yes, but rAF does automatic debouncing and scheduling for us. For me it feels like an improvement over manually doing it. |
As requested in mozilla#5178, this change debounces the scroll events. The reason for doing so is that browsers can event-storm especially on scroll, communicating hundreds of subpixel changes. The main reason for this resulting in poor performance is that on each scroll event `scrollTop` was queried, which forces layouting. This change will use `requestAnimationFrame` to make sure the browser can allocate enough time to other tasks. The delay is however quite small, thus the reduction in executions is less noticeable. Modern browsers however utilize `requestAnimationFrame` to smoothen out rendering.
|
/botio-linux preview |
From: Bot.io (Linux)ReceivedCommand cmd_preview from @timvandermeij received. Current queue size: 0 Live output at: http://107.21.233.14:8877/c2fdb87333af63d/output.txt |
From: Bot.io (Linux)SuccessFull output at http://107.21.233.14:8877/c2fdb87333af63d/output.txt Total script time: 0.75 mins Published
|
Debounces scroll events in web viewer.
|
Thanks |
As requested in #5178, this change debounces the scroll events.
The reason for doing so is that browsers can event-storm especially on
scroll, communicating hundreds of subpixel changes.
The main reason for this resulting in poor performance is that on each
scroll event
scrollTopwas queried, which forces layouting.This change will set the scrolling to happen after 75ms of no more
scrolling happening. This timeout suppresses consecutive scrolls but almost
immediately fires as soon as the user slows down.
Fixes #5178, should improve #5207
For easier review use: https://github.com/mozilla/pdf.js/pull/5208/files?w=1