PSA: Blink scheduler (aka: RendererScheduler) has landed

308 views
Skip to first unread message

Ross McIlroy

unread,
Dec 18, 2014, 11:58:48 AM12/18/14
to blink-dev, pic...@chromium.org, alexc...@chromium.org, Sami Kyostila, mig...@chromium.org
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

unread,
Dec 18, 2014, 12:44:57 PM12/18/14
to Ross McIlroy, blink-dev, pic...@chromium.org, alexc...@chromium.org, Sami Kyostila, mig...@chromium.org
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

unread,
Dec 19, 2014, 4:01:55 PM12/19/14
to Ross McIlroy, blink-dev, pic...@chromium.org, alexc...@chromium.org, Sami Kyostila, mig...@chromium.org
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

unread,
Dec 19, 2014, 6:02:14 PM12/19/14
to Ross McIlroy, Ross McIlroy, blink-dev, pic...@chromium.org, alexc...@chromium.org, Sami Kyostila, mig...@chromium.org
Hey, is there a doc somewhere that describes the performance wins from the scheduler?  /me is curious.

Thanks!
Adam

Daniel Bratell

unread,
Dec 20, 2014, 5:39:36 AM12/20/14
to Ross McIlroy, Ross McIlroy, Adam Barth, blink-dev, pic...@chromium.org, alexc...@chromium.org, Sami Kyostila, mig...@chromium.org
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

unread,
Dec 20, 2014, 5:47:04 AM12/20/14
to blink-dev, Ross McIlroy, pic...@chromium.org, alexc...@chromium.org, Sami Kyostila, mig...@chromium.org
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

unread,
Dec 20, 2014, 2:31:04 PM12/20/14
to Daniel Bratell, Ross McIlroy, Ross McIlroy, blink-dev, pic...@chromium.org, alexc...@chromium.org, Sami Kyostila, mig...@chromium.org
Neat!  Thanks.

Adam
 

Rick Byers

unread,
Dec 20, 2014, 4:55:15 PM12/20/14
to Daniel Bratell, blink-dev, Ross McIlroy, pic...@chromium.org, alexc...@chromium.org, Sami Kyostila, mig...@chromium.org
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

unread,
Dec 21, 2014, 2:48:50 AM12/21/14
to Rick Byers, Daniel Bratell, blink-dev, Ross McIlroy, pic...@chromium.org, alexc...@chromium.org, Sami Kyostila, Miguel Garcia
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

unread,
Dec 22, 2014, 5:47:40 AM12/22/14
to Rick Byers, Elliott Sprehn, blink-dev, Ross McIlroy, pic...@chromium.org, alexc...@chromium.org, Sami Kyostila, Miguel Garcia
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

unread,
Dec 22, 2014, 7:34:03 AM12/22/14
to Daniel Bratell, Rick Byers, Elliott Sprehn, blink-dev, Ross McIlroy, pic...@chromium.org, alexc...@chromium.org, Sami Kyostila, Miguel Garcia
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

unread,
Dec 22, 2014, 12:30:27 PM12/22/14
to Ross McIlroy, Ross McIlroy, blink-dev, pic...@chromium.org, Alex Clarke, Sami Kyostila, mig...@chromium.org
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

unread,
Dec 22, 2014, 1:02:06 PM12/22/14
to Alex Clarke, Ross McIlroy, Ross McIlroy, blink-dev, pic...@chromium.org, Alex Clarke, Sami Kyostila, mig...@chromium.org


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

unread,
Dec 22, 2014, 1:14:28 PM12/22/14
to Elliott Sprehn, blink-dev, mig...@chromium.org, Sami Kyostila, Ross McIlroy, pic...@chromium.org, Alex Clarke, Ross McIlroy

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

unread,
Dec 23, 2014, 3:47:55 PM12/23/14
to Adam Barth, Ross McIlroy, Ross McIlroy, blink-dev, pic...@chromium.org, Alex Clarke, Sami Kyostila, mig...@chromium.org
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

unread,
Jan 9, 2015, 2:37:12 PM1/9/15
to Ross McIlroy, Ross McIlroy, blink-dev, pic...@chromium.org, Alex Clarke, Sami Kyostila, mig...@chromium.org

The Blink Scheduler is now turned on everywhere.

Chris Harrelson

unread,
Jan 9, 2015, 2:41:49 PM1/9/15
to Alex Clarke, Ross McIlroy, Ross McIlroy, blink-dev, pic...@chromium.org, Alex Clarke, Sami Kyostila, mig...@chromium.org
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.

Reply all
Reply to author
Forward
0 new messages