PSA: Blink scheduler (aka: RendererScheduler) has landed

[Ross McIlroy]

We have just landed a change which enables the Blink Scheduler (aka the RendererScheduler) by default in Chrome (more details here and here).  

When we did this a month ago it started causing LayoutTests flakes.  We have since spent the last month fixing up these issues (see http://crbug.com/432129 for details) and think we are in a good place to reland, but want to inform the blink-dev list to provide a heads-up.

In our experience, the majority of flakes are due to tests depending on the order of parsing and rendering, which is not guaranteed and becomes less likely to hold when the scheduler is enabled (even without the scheduler enabled these test occasionally flake in the same way).  Many of these tests can be forced to fail by introducing an artificial delay as described in http://crbug.com/440008.

Please let us know if you see any previously stable LayoutTests becoming flaky after this change, and associate any TestExpectations changes due to this with http://crbug.com/432129.  The majority of these flakes will have one of the following symptoms:

   - timeout (e.g., due to an event happening before an event listener was registered)

   - render tree dump including additional anonymous render blocks (due to layout pass timing differences)

   - extra console output or reordered console output

   - a visible progress bar on image tests

   - animation related flake (e.g., animating an extra frame compared to usual)

There are a few test which we have marked as flaky in TestExpectations which which will deflake and re-enable in the new year.  Please don't hesitate to contact us if you experience any issues.

Thanks,

The Blink scheduler team (alexclarke@, picksi@, rmcilroy@, skyostil@)

[Ross McIlroy]

A copy and paste fail stripped the links from this email.  The "here and here" were meant to be links to our BlinkOn presentation and the design doc respectively.  The change itself is here.

Cheers,

Ross

[Ross McIlroy]

To update this thread - enabling the Blink Scheduler has been delayed due to an issue with nested message queues on some ChromeOS and Android instrumentation tests.  I'll update this thread when it finally lands.

Cheers,

Ross

[Adam Barth]

Hey, is there a doc somewhere that describes the performance wins from the scheduler?  /me is curious.

Thanks!

Adam

[Daniel Bratell]

On Sat, 20 Dec 2014 00:02:08 +0100, Adam Barth <aba...@chromium.org> wrote:

Hey, is there a doc somewhere that describes the performance wins from the scheduler?  /me is curious.

Slide 40 and 41 in the BlinkOn presentation ( https://docs.google.com/presentation/d/1V09Qq08_jOucvOFs-C7P4Hz2Vsswa6imqLxAf7ONomQ/view?pli=1#slide=id.g4eb5cd017_725 ) show some very definite improvements to input latency and "smoothness". Maybe they have more data now, 6 weeks later.

/Daniel

[Daniel Bratell]

On Thu, 18 Dec 2014 17:58:22 +0100, Ross McIlroy <rmci...@chromium.org> wrote:

We have just landed a change which enables the Blink Scheduler (aka the RendererScheduler) by default in Chrome (more details here and here).  

This makes me very excited because I think this is a necessary and critical step towards making the browser a good application platform, so big cheers from me in your general direction.

That testcases make a lot of assumptions is unfortunate, but not unexpected. Sometimes I wonder if something can be done to shake down all tests that make unreliable assumptions. Something that doesn't mean delaying unrelated important projects.

Then I have an idea/question. This is not totally unfamiliar territory to those of us that worked with Presto in the past and one thing I was thinking of doing but never came round to implementing there was to merge mouse move events (as some operating systems already do so nothing completely new).

When a mousemove handler (touch events probably apply as well) needs more than 1 frame to process and you get 1 mousemove event every frame, all that happens is that the page lags farther and farther behind. With the different queues if might be obvious that there is a sequence of mousemove events and if they are all old, it might be better to just merge them all.

/Daniel

[Adam Barth]

Neat!  Thanks.

Adam

 

[Rick Byers]

Yep, we've always done this (at least as for as long back as I've cared to look) - we call it "event coalescing" and we apply it (with some type-specific details) to mouse movement, wheel scrolls, touch movement and gesture scroll/pinch events.  But it's the chromium content layer that implements this, not blink (to prevent possible IPC message pileup if the renderer is slow).  In general there's at most one of each of these types of events "in flight" (sent to a renderer without an ACK response being received) per RenderWidget at any given time. See content::InputRouterImpl and content::TouchEventQueue.

This system is far from perfect though.  For example, it's probably not what a developer of a handwriting recognition / painting system wants (they'd rather get more complete but delayed data).  At some point I'd like to explore adding new APIs to request the "event history" (up to some limit), similar to Android's historical events.

/Daniel

[Elliott Sprehn]

On Sat, Dec 20, 2014 at 1:54 PM, Rick Byers <rby...@chromium.org> wrote:

On Sat, Dec 20, 2014 at 5:46 AM, Daniel Bratell <bra...@opera.com> wrote:

On Thu, 18 Dec 2014 17:58:22 +0100, Ross McIlroy <rmci...@chromium.org> wrote:

We have just landed a change which enables the Blink Scheduler (aka the RendererScheduler) by default in Chrome (more details here and here).  

...

Then I have an idea/question. This is not totally unfamiliar territory to those of us that worked with Presto in the past and one thing I was thinking of doing but never came round to implementing there was to merge mouse move events (as some operating systems already do so nothing completely new).

...

Yep, we've always done this (at least as for as long back as I've cared to look) - we call it "event coalescing" and we apply it (with some type-specific details) to mouse movement, wheel scrolls, touch movement and gesture scroll/pinch events.  But it's the chromium content layer that implements this, not blink (to prevent possible IPC message pileup if the renderer is slow).  In general there's at most one of each of these types of events "in flight" (sent to a renderer without an ACK response being received) per RenderWidget at any given time. See content::InputRouterImpl and content::TouchEventQueue.

We also do something similar for scroll and resize events inside blink. You'll only ever get one scroll event per scrollable area per frame, and one resize event per document per frame.

- E

[Daniel Bratell]

Nice! (Unless you're an artist of some kind and hate losing input events as Rick said).

How does it work with touch events which contains more than just coordinates?

/Daniel

[Ross McIlroy]

On 19 December 2014 at 23:02, Adam Barth <aba...@chromium.org> wrote:

Hey, is there a doc somewhere that describes the performance wins from the scheduler?  /me is curious.

As Daniel mentioned, the initial focus has been on prioritizing compositor and input tasks during input handling, which leads to improvements on the input latency and "smoothness" metrics.  

Once we have enabled the scheduler in it's current form we will be working on extending the types of task prioritisation we do (e.g., scheduling resource loading tasks differently depending upon how much of the page is loaded).  We are also going to move non-time-critical tasks (e.g., incremental marking in the V8 GC) into "idle time", both in inter-frame idle periods (when the current frame is already composited by the next frame hasn't begun yet) and for longer periods during no user interaction - this should reduce jank by ensuring this work is done when it is least likely to impact the user, but we are still working on a good benchmark to show this. More details are in this design doc.

On 20 December 2014 at 10:46, Daniel Bratell <bra...@opera.com> wrote:

This makes me very excited because I think this is a necessary and critical step towards making the browser a good application platform, so big cheers from me in your general direction.

Great, glad you are as excited as we are :).

 

That testcases make a lot of assumptions is unfortunate, but not unexpected. Sometimes I wonder if something can be done to shake down all tests that make unreliable assumptions. Something that doesn't mean delaying unrelated important projects.

We are planning on writing up a document on "what not to do when writing LayoutTests" based on our experiences in fixing up these tests to work with the scheduler.  We are also hoping to set up an FYI bot which runs the tests either with the artificial delays described in http://crbug.com/440008 or with random (but repeatable) scheduling to show tests which may be flaky due to making these types of assumptions.

Cheers,

Ross

[Alex Clarke]

An update, the Blink Scheduler has now landed but it's disabled on ChromeOS and Android Web View.  We intend to try and turn it on everywhere in the new year.

[Elliott Sprehn]

On Monday, December 22, 2014, 'Alex Clarke' via blink-dev <blin...@chromium.org> wrote:

An update, the Blink Scheduler has now landed but it's disabled on ChromeOS and Android Web View.  We intend to try and turn it on everywhere in the new year.

What's different about chrome os? It should behave the same as windows and other aura platforms.

[Alex Clarke]

Some of the chromeos tests where failing.  We think this is related to the way the scheduler interacts with nested runloops rather than anything ChromeOS specific.

[Alex Clarke]

The Scheduler has been landed for a bit over a day now(since #309435) and we have some initial results from the perf bots.

Key mobile sites:

Input Event Latency has improved.

Top 25 Smooth:

First Gesture Scroll Update (time it takes for the page to start scrolling) has improved, as has queueing durations, and mean_scroll_update_latency seems improved on nexus 4&7

[Alex Clarke]

The Blink Scheduler is now turned on everywhere.

[Chris Harrelson]

Awesome! Great work, this is very exciting.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.