Intent to Implement: Impl threaded scrollbar scrolling

[Rahul Arakeri]

Hello blink-dev,

 

Please take a look at the attached intent to implement for Impl threaded scrollbar scrolling.

 

Quick Summary:

This proposal is to move composited scrollbar scrolling to the impl thread so that even when the main thread is busy, users can continue to interact with and scroll using scrollbars. The code will live mostly in cc.

 

Thanks,

Rahul

[Rahul Arakeri]

Pasting the contents here:

 

Impl threaded scrollbar scrolling

 

Subject

Intent to implement Impl threaded composited scrollbar scrolling for MouseEvent(s).

Contact emails

ara...@microsoft.com, sam...@microsoft.com, dli...@microsoft.com, ri...@microsoft.com, mar...@microsoft.com

Design doc/spec

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Scrolling/ImplScrollbars/dev-diagram.md

Summary

This proposal is to move composited scrollbar scrolling to the impl thread so that even when the main thread is busy, users can continue to interact with and scroll using scrollbars. The code will live mostly in cc.

Motivation

Scrollbar scrolling using the mouse happens on the main thread in Chromium. If the main thread is busy (due to reasons like long running JS, etc), scrolling by clicking on the scrollbar will appear to be janky as the events keep getting queued up on the MainThreadEventQueue, waiting for the main thread to free up. We observe on average scrollbar drags have ~2-4x higher latency in Chromium as compared to EdgeHTML today, worse on particularly busy sites.  We attribute this gap primarily to EdgeHTML’s feature for off-thread scrollbar drags.  By avoiding the main thread in Chromium as well, we believe we can bring the performance of scrollbar drags more in line with what we observe in EdgeHTML.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Ongoing technical constraints

None (and this feature will be staged using a base::Feature flag)

Tracking bug

938619

Demo links

Attachment to crbug.com/938619: https://bugs.chromium.org/p/chromium/issues/attachment?aid=382732&signed_aid=sAa8q1u-nTAvDsa4W8HQvA==

[Stephen Mcgruer]

Hi Rahul,

This is exciting! I would love to see more smooth scrolling in Chrome.

Ian (cc'd) and I were chatting today and were wondering if (and how) you plan to handle updating the scrollbar visuals on the compositor. If this was left to main (as it is today for wheel scrolls), then when main is busy the user could 'grab' the scrollbar and drag it, and see the contents move smoothly but the scrollbar lag behind - which might be confusing for the user.

Drawing the scrollbar on the compositor is made more complex by the various pseudo-selectors that Chrome supports. Take for example the beautiful example that is https://output.jsbin.com/tahugop - a composited scroller, but non-trivial to draw (repeating, stretching images, gradients, etc). I'm not sure if any of those pseudo-selectors can cause content that is impossible for the compositor to draw, but certainly could be tricky! :)

Thanks,

Stephen

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BYAPR21MB127109AF1E81EAAB8A3CA9DDA64E0%40BYAPR21MB1271.namprd21.prod.outlook.com.

[David Bokan]

I can speak to this as I've been working with Rahul on the design.

The design as stated will work only on composited scrollers. If the scroller is uncomposited, we don't get a cc::Layer for it nor its scrollbars so there's nothing for us to grab there. The goal here is to allow composited scrollers to scroll on the compositor thread when manipulating scrollbars; today we fallback to main as that's where the mouse event handling code lives. We have no plan (here) to make main thread scrollers scroll off the compositor thread somehow.

The (very) long term plan is a combination of scroll unification (removing gesture handling from blink) and raster-inducing scroll.

With scroll unification, CC will "know" about _all_ scrollers, even uncomposited ones. This means, given enough information/rects from Blink, we can find and mutate an uncomposited ScrollNode in Blink and force a commit. This won't provide (significant) performance improvements on its own, but it does remove all the code duplication that exists today.

However, if we then add raster-inducing scroll (and composite after paint, which is a pre-req), it will allow us to reraster already painted scrolling contents without going back to Blink. I believe most of the reasons we have to force main thread scrolling today is paint-order (bad compositing decisions) and raster-related reasons. Once we have all these pieces in place, we should be able to perform scrolling off the main thread in most (all?) cases. 

[Stephen Mcgruer]

Thanks for the thorough answer David, sgtm.

One minor nit: we should be careful about terminology. The scroller in my lovely cat example is composited (in my eyes); there are layers for the contents, the scrollbars, and the scroll corner (on Linux)*. It also has composited wheel scrolling, so scrolling the contents will be smooth under main thread jank. What is 'wrong' is that the compositor is unable to render the scrollbar thumb or the tracks without main-thread involvement. I don't think there's any succinct way to describe this, but maybe I'm just not up to date on terminology :D.

* Fun fact: on an example where the compositor *is* able to move the scrollbar today without the main thread involvement (https://output.jsbin.com/marimex/3, on Linux again), there are only two layers - the contents and the scroll corner. Layering is fun.

[Adrienne Walker]

cc has three different kinds of scrollbars that it deals with, all are subclasses of ScrollbarLayerInterface.  All three of these types of scrollbars update on the compositor thread with respect to the current scroll position.  The "painted" scrollbar types have two resources, track and thumb, and moving the scroller adjusts the position of the thumb in the track.  There's also solid color scrollbars that we draw directly.  Even though they emit multiple quads, all scrollbar layers are still a single layer with respect to cc.

Themed scrollbars can't be represented as just a track and a thumb (as you can do things like color one side of the track differently than the other, etc) and so they behave like normal content on the page.  Such scrollbars don't update scroll positions on the compositor thread, but they might still be a composited (PictureLayer) themselves.  We raster the bitmaps for the painted scrollbar resources all on the main thread and that's why we can't update these scrollbars when they scroll.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Maf1%2Boh4AZH2A6ewd5qz7E96QP1k3rDCP1iWtMR%2BfcfvsA%40mail.gmail.com.

[Rahul Arakeri]

Thanks for all your inputs :)

 

As David rightly said, this intent is scoped to handling composited scrollbars only. We have a CL up for handling mouse clicks on composited scrollbar arrows and are currently working out the specifics of other composited scrollbar mouse interactions (like thumb drag, keeping the mouse pressed on the arrows/track etc).

[Rahul Arakeri]

Hi everyone,

 

Quick update. A couple of days ago, we landed a changelist which enables support for compositor threaded scrollbar scrolling using arrows (for now).

Chrome Canary (75.0.3769.0 and higher) should have the change. You can use this test page for reference: https://rahul8805.github.io/DemoPages/main_thread_jank.html

Thanks to all the code reviewers !

 

In the coming days, we’ll keep adding more functionality to it 😊

 

Thanks,

Rahul

[Rahul Arakeri]

Updates:

 

More functionality (+a couple of bug fixes) has been added. Scrollbar thumb drag on the compositor thread is now supported (landed last week). Those interested in checking it out, please feel free to use this demo page.

 

We’re continuing to add more functionality. Continuous-scrolling (for when you click and hold the scrollbar arrow) is currently being prototyped. Thank you for all the advice and code review feedback. 😊

[Rahul Arakeri]

Update:

 

We’ve merged a couple of changelists that enable autoscrolling (for both, arrow and track). Please feel free to check it out using this demo page. There are still outstanding bugs that are currently being worked on.

 

Thanks to the code reviewers ! If you have any questions, please don’t hesitate to reach out 😊

 

Thanks,

Rahul Arakeri

[Rahul Arakeri]

More updates:

 

Improvements to smooth autoscrolling (like infinite autoscrolling) and thumb dragging (like anchoring) have now been merged. Please feel free to check it out 😊

Demo page: https://rahul8805.github.io/DemoPages/main_thread_jank.html

 

PS :

(Based on a Slack discussion with David Bokan about the scope).

Please note that thumb invalidation (i.e changing the color of the thumb on hover on/off) and custom scrollbars scrolling will still happen on the main thread. These need additional work and are currently out of scope for the composited scrollbar scrolling.

[Luciano Pacheco]

Hi, 

I've just got a weird scroll behaviour on Chrome Dev channel:  crbug.com/1000547

It leaves a rendering trace from the scroll bar from a <iframe> when scrolling the main window see the screencast below:

https://drive.google.com/file/d/1TzZhyTvXvXQTdWI3oWxC_jw_Z1OA1e5_/view

Sharing here in case it's related.

Cheers.

On Wednesday, September 4, 2019 at 4:38:13 AM UTC+10, Rahul Arakeri wrote:

More updates:

 

Improvements to smooth autoscrolling (like infinite autoscrolling) and thumb dragging (like anchoring) have now been merged. Please feel free to check it out 😊

Demo page: https://rahul8805.github.io/DemoPages/main_thread_jank.html

 

PS :

(Based on a Slack discussion with David Bokan about the scope).

Please note that thumb invalidation (i.e changing the color of the thumb on hover on/off) and custom scrollbars scrolling will still happen on the main thread. These need additional work and are currently out of scope for the composited scrollbar scrolling.

 

Thanks,

Rahul

[....] 

[David Bokan]

That looks like a graphical glitch so I don't expect it would be related to the new scrollbar handler code. Will follow-up in the bug.

[ara...@microsoft.com]

September update. The following were implemented:

- Autoscroll play/pause.

- Fixes for jittery thumb drag.

- Shift + click on scrollbar

- Thumb snapping.

As always, please feel free to try these out on the latest Chrome Canary using this demo page:

https://rahul8805.github.io/DemoPages/main_thread_jank.html

Thanks,

Rahul

[Rahul Arakeri]

Time for another update !

October was focused mostly on Mac:

- Fixed hit testing bugs that enabled clicking on the track.

- Implemented Option + click on scrollbar track (i.e non-animated jump)

- Fixed bugs related to device scale factor.

- Fixed flaky tests.

- Started cleaning up tests and prepping them for re-enabling.

Test page: https://rahul8805.github.io/DemoPages/BouncyMoon.html

Design doc: https://docs.google.com/document/d/1JqykSXnCkqwA1E3bUhhIi-IgEvM9HZdKtIu_S4Ncm6o/edit?usp=sharing

Lightning talk about the feature: https://www.youtube.com/watch?v=FOCHCuGA_MA&t=1150s

Thanks,

Rahul

[Rahul Arakeri]

Hi everyone,

After a bunch of work, compositor threaded scrollbar scrolling is finally on by default in chromium master. Today’s Chrome canary (82.0.4072.0) has it ON. Thanks to all those who helped and guided me along the way. This will be a perf win for scrolling on chromium based browsers and takes us all one step closer towards scrolling unification. 😃

Please feel free to reach out to me if you have any questions.

Rahul Arakeri: ara...@microsoft.com

Additional info:

Design doc: https://docs.google.com/document/d/1JqykSXnCkqwA1E3bUhhIi-IgEvM9HZdKtIu_S4Ncm6o

Demo page: https://rahul8805.github.io/DemoPages/BouncyMoon.html

Lightning talk: https://www.youtube.com/watch?v=FOCHCuGA_MA&t=1150s

 

Example of scrollbar drag when main thread is busy:

 

FEATURE OFF

Histogram: Event.Latency.ScrollUpdate.Scrollbar.TimeToScrollUpdateSwapBegin4 recorded 19 samples, mean = 240325.4 (flags = 0x41)

0       ...

109350  ----O                                                                     (1 = 5.3%) {0.0%}

126669  ...

169971  ----O                                                                     (1 = 5.3%) {5.3%}

196891  O                                                                         (0 = 0.0%) {10.5%}

228075  ------------------------------------------------------------------------O (17 = 89.5%) {10.5%}

264198  ...

 

FEATURE ON

Histogram: Event.Latency.ScrollUpdate.Scrollbar.TimeToScrollUpdateSwapBegin4 recorded 58 samples, mean = 14517.3 (flags = 0x41)

0      ...

10403  -----------------------------------------------O                          (11 = 19.0%) {0.0%}

12051  -----------------------------------------------------------O              (14 = 24.1%) {19.0%}

13960  ------------------------------------------------------------------------O (17 = 29.3%) {43.1%}

16171  -----------------------------------------------------------O              (14 = 24.1%) {72.4%}

18732  --------O                                                                 (2 = 3.4%) {96.6%}

21699  ...

Thanks,

Rahul

[Chris Harrelson]

Excellent work! These performance numbers look amazing.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9a0cd072-7533-4aef-b590-b6d2a383fa18%40chromium.org.