[Webkit-unassigned] [Bug 232376] twitch.tv forces synchronous scrolling

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Nov 10 03:03:12 PST 2021


Chris Lord <clord at igalia.com> changed:

           What    |Removed                     |Added
            Summary|[GTK] Smooth scrolling      |twitch.tv forces
                   |doesn't work on twitch.tv   |synchronous scrolling

--- Comment #2 from Chris Lord <clord at igalia.com> ---
Retitling this bug - Alejandro García Castro and I have been looking at this, and the issue is that Twitch.tv draws a custom scroll indicator and hooks onto all scroll events to do this. It seems just the act of hooking onto these events causes the region to be marked for main-thread-first event handling, and so ends up disabling asynchronous scrolling entirely. Because the page render performance is terrible and frequently updates, the scrolling also feels terrible.

I can't tell if this is handled differently in Chrome because the page render performance is so much better that it isn't obvious. However, in Firefox, I know this isn't how it's handled (both from observation and from having worked on the code in the past). Scrolling the same page in Firefox is perfectly smooth, but you can see the scroll indicator updating in a jerky manner, presumably because that's the actual page update performance.

Assuming Firefox hasn't changed and I recall correctly, when handling events like this in Firefox, the main thread is given a grace period to block the event in the scroll handler and if it can't respond in that time, the event will be delivered regardless. If subsequent events are part of an ongoing async scroll gesture, they will be delivered straight to the equivalent of the scrolling thread.

While I need to see if this is covered in any related standards, I think it would be a good idea to match the behaviour in Firefox. This page, for example, has regular hundred-millisecond rendering pauses on even desktop-class hardware. It is practically unusable on low-power embedded devices and completely negates the point of async scrolling. It should not be so easy to disable async scrolling (it doesn't actually block any of the scroll events, it just listens to them to update its scroll indicator).

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20211110/a60419cc/attachment.htm>

More information about the webkit-unassigned mailing list