Re: When are we in composited scrolling?

[Rick Byers]

+input-dev since I think this is an important discussion.

What matters most for perf, IMHO, is whether you're getting accelerated scrolling.  That's relatively easy to see in devtools - just enable 'show paint rectanges' and verify you're not getting green flashes across your scroller while scrolling.

Typically for touch accelerated scrolling == impl-thread scrolling (since the main reason NOT to get impl-thread scrolling is because it can't be accelerated), but that's not strictly always the case.  I think chrome://tracing is the only easy way to verify you're actually getting threaded scrolling (see which thread is handling the GestureScrollUpdate events).  Have we seen any examples where it's important for developers to understand this distinction?  For mouse scrolling, wheel handlers force main thread scrolling even when it can be accelerated.

Regardless I think this should be exposed in devtools along with our RAIL work somehow.  However we're going to annotate that scrolling is occurring, we should be clear on whether it's the 'R' rule that applies (100ms to start scroll because you've got threaded scrolling) or the 'A' rule (6ms in each scroll frame because scrolling is happening on main).

Rick

On Thu, Apr 16, 2015 at 11:33 AM, Jared Duke <jdd...@google.com> wrote:

But your point still stands. I believe we have async traces for flings on the compositor thread, but we should probably move that to the shared fling implementation so we get "free" coverage for both impl/main.

On Thu, Apr 16, 2015 at 8:30 AM, Jared Duke <jdd...@google.com> wrote:

That's only for touchpad flings.

On Thu, Apr 16, 2015 at 8:28 AM, Timothy Dresser <tdre...@google.com> wrote:

For touch scrolling, fling is a bit tricky, as it can switch from impl to main.

On Thu, Apr 16, 2015 at 11:20 AM Jared Duke <jdd...@google.com> wrote:

Improving visibility of main vs impl scrolling is a great idea, particularly as we expose more controls that will increase the likelihood of main thread scrolling. I know various proposals have been toyed with in the past, from an indicator on the FPS hud to improved trace visibility, but I don't believe anything concrete has landed (outside of manual inspection). 

Yufeng, perhaps we should resurrect some of these ideas, e.g., crbug.com/131499? For touch scrolling it should be pretty simple, as we have explicit begin/end scroll event pairs that bound the scroll sequence and are locked to a given thread.

For UMA, I think the only metric we have is Renderer4.CompositorScrollHitTestResult. This effectively shows that 99.7% of touch scrolls on Android use threaded scrolling (a fact that likely influenced our willingness to invest in improved visibility).

On Wed, Apr 15, 2015 at 3:45 PM, Paul Irish <paul...@google.com> wrote:

(Feel free to reroute this to an appropriate list)

We handle things very differently when we're in composited vs main thread scrolling, but AFAIK we have no visibility during active profiling, benchmarking, or in the wild.

• As a web developer: Since we treat scroll events differently, knowing which mode I'm in helps me prioritize the right perf work.
• As Chrome eng: Should we validate our scrolling mode hypotheses when viewing a trace?
• As Chrome eng: Do we have insight on what mode our users are in? Can we measure this somehow in UMA?

Or perhaps you can tell me we already have this info being tracked somewhere. *crosses fingers*

[Alexandre Elias]

Well, both accelerated and impl thread matter a lot, in my opinion.  I agree the distinction is hard to explain to developers though, so I'd suggest a binary split: labeling either failure to accelerate or to impl-thread as "slow/risk of slow" and having both as "fast".

[Paul Irish]

This is super useful. Thanks guys.

> I am also planning to add the mode to the RAIL auditing UI in trace viewer. 

Sounds good. 

We'll want our "scroll gesture" in the audit to have a property indicating which scrolling mode we're in.

I'll have DevTools piggyback off that approach.

---

UMA results summarized: 

• The Renderer4.CompositorScrollHitTestResult indicates 97-99% of scrolls are composited.
  
• Event.Latency.ScrollUpdate.TouchToHandled_Impl/_Main counts indicate >99% of scroll gestures handled on impl thread.

Those are great numbers. So happy to see it.

---

>  I agree the distinction is hard to explain to developers though,

For sure. TBH this is the first time I've learned we have not two but three modes of scrolling. :)

1. impl-thread, accelerated scrolling 
2. accelerated scrolling
3. main thread scrolling

The "Show potential scroll bottlenecks" annotation indicates why we're in #3, right? Is it still correctly identifying all reasons?

Under what circumstances do we hit #2 (on Android)?

​

[Rick Byers]

On Fri, Apr 17, 2015 at 6:03 PM, Paul Irish <paul...@google.com> wrote:

This is super useful. Thanks guys.

> I am also planning to add the mode to the RAIL auditing UI in trace viewer. 

Sounds good. 

We'll want our "scroll gesture" in the audit to have a property indicating which scrolling mode we're in.

I'll have DevTools piggyback off that approach.

---

UMA results summarized: 

• The Renderer4.CompositorScrollHitTestResult indicates 97-99% of scrolls are composited.
  
• Event.Latency.ScrollUpdate.TouchToHandled_Impl/_Main counts indicate >99% of scroll gestures handled on impl thread.

Those are great numbers. So happy to see it.

---

>  I agree the distinction is hard to explain to developers though,

For sure. TBH this is the first time I've learned we have not two but three modes of scrolling. :)

1. impl-thread, accelerated scrolling 
2. accelerated scrolling

I'd call this "accelerated main-thread scrolling".  Depending on the site this can be OK.  We used to call sites where this was OK "silky" (eg. google maps).  Now I'd just say that for rail, the 'A' is either on main or impl (just like animations - may be CSS or requestAnimationFrame).  Main thread accelerated scrolling is really now worse than touchmove handling or requestAnimationFrame-style animations, but it means you have perf-critical stuff on your main thread so the 'A' budget applies to ALL your javascript.  When all your animations/scrolling are impl-thread, then 'A' doesn't really apply anymore (or more accurately it applies to the impl thread instead of the main thread - something the developer doesn't control as directly).

1. 3. main thread scrolling

I think we typically call this "slow scrolling".  Not to be confused with the above, this is basically ALWAYS terrible.

The "Show potential scroll bottlenecks" annotation indicates why we're in #3, right? Is it still correctly identifying all reasons?

Under what circumstances do we hit #2 (on Android)?

Repaint rects / paint profiling show why we're in 3.  show potential scroll bottlenecks show why we're on main (#2 or #3).