Intent to Implement: APIs for Main Thread Scheduling

[Shubhie Panicker]

Contact emails

{panicker, szager, shaseley}@chromium.org

Explainer

https://github.com/spanicker/main-thread-scheduling/blob/master/README.md

Tag review: https://github.com/w3ctag/design-reviews/issues/338

Summary

This (umbrella) intent covers a set of proposed APIs for main thread scheduling, for improved user responsiveness. Separate Intents will also be sent for individual APIs.

Motivation

It is too difficult to build web apps that are responsive to user interaction, and that remain responsive over time. Script is a primary culprit that hurts responsiveness.

Consider a "search-as-you-type" application: this app needs to be responsive to user input i.e. user typing in the search-box. At the same time any animations on the page must be rendered smoothly, as well as the work for fetching, preparing and displaying search results must progress quickly.

This is a lot of different deadlines for an app developer to contend with; it is hard to reason about and correctly use myriad existing APIs as well workarounds for missing hooks.

Today this also requires an understanding of the browser’s rendering engine to plug into the right places. It is easy for script running at inopportune times to hold up the main thread and cause responsiveness issues.

This problem can be tackled by systematically chunking and scheduling main thread work i.e. prioritizing and executing work async at an appropriate time relative to current situation of user and browser. This proposal explores a set of APIs to achieve this, towards the goal of improving guarantees of responsiveness.

Concretely, we will:

I. Develop (low level) primitives to enable Javascript / userland schedulers to succeed: this effort focuses on filling gaps in existing scheduling primitives.

II. Develop a proof-of-concept for a native platform scheduler, that is directly integrated into the browser's event-loop.

Risks

Interoperability risk: medium

If other browsers do not implement the APIs, the situation is no worse than today; it will be possible to feature detect and take advantage of improved scheduling on browsers that do ship the API.

The APIs have been discussed in web-perf WG at TPAC 2018.

There is interest from browsers in the problem of enabling effective scheduling and helping frameworks and userspace schedulers to succeed in this space.

The sentiment was positive overall for low level primitives such as render-frame budget, input pending etc.

For a native scheduling API, there was no opposition, and there is interest in developing a proof-of-concept while working closely with partners. For details, see my TPAC trip report here as well as TPAC web-perf notes.

Also note that there is strong interest from developer community in the proposal, we are working with a number of web developers and framework developers to whet the proposals and iterate on the APIs eg. React, Google Maps, Ember, Vue, Airbnb etc. For details on who’s interested in which APIs see list of partners here, whom we will reach out to partake in Origin Trials.

Compatibility risk: low

Scheduling APIs should not cause breakage or degradation of content.

Note that these APIs will not add new surface that would escape throttling and freezing of background and offscreen content.

Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with? The low level primitives will be used along with existing APIs such as requestAnimationFrame, settimeout, requestIdleCallback etc.

Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)? No.

Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is? No, these APIs will be typically used by framework libraries.

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use? Likely.

Debuggability

No special Devtools support is needed.

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

Yes.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/6031161734201344

Requesting approval to ship?

No.

[Jochen Eisinger]

Hey,

wondering how you plan to avoid cross origin information leaks?

best

-jochen

--
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/CAK7ODi8H6%3Dk5nCW-wnS_rHdF1EKE6syZ707Kvr0awDJ1jj5B_w%40mail.gmail.com.

[Joe Medley]

Shubhie,

Do you have a tracking bug for this?

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

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/CALjhuieJgsfW8Y61f5svaQGURJLRvWP6zOnJWT4kRSKk5Fs8CQ%40mail.gmail.com.

[Shubhie Panicker]

Apologies for the delay (just back from being out of office).

On Mon, Jan 28, 2019 at 12:49 AM Jochen Eisinger <joc...@chromium.org> wrote:

Hey,

wondering how you plan to avoid cross origin information leaks?

For which API specifically? This is an umbrella Intent for several APIs and each one will have it's own Intent, explainer and security considerations section.

For example: https://github.com/WICG/is-input-pending#privacy-and-security

 

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/CALjhuieJgsfW8Y61f5svaQGURJLRvWP6zOnJWT4kRSKk5Fs8CQ%40mail.gmail.com.

[Shubhie Panicker]

On Tue, Jan 29, 2019 at 7:27 AM Joe Medley <jme...@google.com> wrote:

Shubhie,

Do you have a tracking bug for this?

Each API will have its own tracking bug. Happy to create one for umbrella effort, but not sure why that is needed? 

[Joe Medley]

The status entry has to have a link to a tracking but. If this is several APIs, then you'll want to give each one it's own status entry. You can repurpose the one you've already made for whichever you work on first.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Todd Reifsteck]

This is significant work and has potential.

 

The Native Scheduling API is potentially very powerful AND can potentially introduce new foot-guns.

 

When should we expect to see concrete proposal options for the Native Scheduling API so that Pros/Cons can be evaluated?

 

-Todd

--

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/CAK7ODi8H6%3Dk5nCW-wnS_rHdF1EKE6syZ707Kvr0awDJ1jj5B_w%40mail.gmail.com.

[stefan.lo...@gmail.com]

Hello!

Thanks to all of those who have worked on implementing the new scheduler!

I'd like to follow up on a note in the original document:

We plan to evaluate, however, whether or not the API is a good fit for workers as we move forward.

I'm very interested in seeing if the current scheduler code could work in a web worker. With the advent of OffscreenCanvas and with WebGPU around the corner, I imagine that having a scheduler in the worker context would be very useful for rendering pipelines running off the main thread.

Thanks!

On Friday, January 25, 2019 at 4:44:56 PM UTC-8, Shubhie Panicker wrote:

Contact emails

{panicker, szager, shas...@chromium.org

[Scott Haseley]

Hi,

Thanks for sharing that use case. We are planning to make postTask available on workers (see this explainer pull request that I was about to land :)), but haven't implemented it in Chromium so it's not available for origin trial or behind a flag just yet.

 - Scott

[Stefan Novak]

Great! Thanks for the quick response!

--

Stefan Novak

[Stefan Novak]

Hello!

I had a chance to tinker around with the new scheduler API and it's pretty cool! From what I've been able to observe, when posting a task to a scheduler, any nested function calls in the task will be split into separate, additional tasks. For example, in the screenshot below, I've submitted a task along the lines of scheduler.postTask(() => render(), {priority: ...}}. I can see that any function calls made in render() result in a new task being executed, which incurs ~0.7-1.0ms of latency for each function call. (In the diagram, all of the function calls in the red box are part of the same function call, as far as I can tell.) For complex tasks, this additional latency could be considered unacceptable, such as rendering pipelines.

Additionally, when I queue up a large number of tasks, I observe dropping of frames (regardless of the priority I've specified for those tasks). For example, in the below screenshot, there are two frames being rendered (as seen by the small green boxes on the left/right side.) During this time, there are two types of tasks that are continuously being posted to the scheduler: adding data to a data visualization and processing user input to change zoom levels. Putting aside the accumulation of latency between nested function calls, a frame doesn't get rendered for 200ms. How can I ensure that frames aren't dropped?

Thanks again for all of the hard work that has been going into the scheduler!

--

Stefan Novak

[Scott Haseley]

On Fri, Apr 24, 2020 at 10:45 AM Stefan Novak <stefan.lo...@gmail.com> wrote:

Hello!

I had a chance to tinker around with the new scheduler API and it's pretty cool! From what I've been able to observe, when posting a task to a scheduler, any nested function calls in the task will be split into separate, additional tasks. For example, in the screenshot below, I've submitted a task along the lines of scheduler.postTask(() => render(), {priority: ...}}. I can see that any function calls made in render() result in a new task being executed, which incurs ~0.7-1.0ms of latency for each function call. (In the diagram, all of the function calls in the red box are part of the same function call, as far as I can tell.) For complex tasks, this additional latency could be considered unacceptable, such as rendering pipelines.

scheduler.postTask schedules a macrotask that runs the provided callback in a turn of the event loop, but it doesn't do anything special with functions invoked in that callback. For example:

function foo() {

  bar();

}

scheduler.postTask(foo);

foo runs in a new task (it's scheduled), and bar synchronously runs when foo executes. In your example, render should always execute in a top-level task because it's wrapped in a postTask, but function calls it makes should not be, unless they're also wrapped in postTasks.

Regarding overhead, scheduler.postTask is a fairly thin wrapper around existing Blink task scheduling / bindings layer functionality, and it would be worth taking a look to see if there's anything that can be optimized. Please feel free to file a crbug with your traces, etc.

Additionally, when I queue up a large number of tasks, I observe dropping of frames (regardless of the priority I've specified for those tasks). For example, in the below screenshot, there are two frames being rendered (as seen by the small green boxes on the left/right side.) During this time, there are two types of tasks that are continuously being posted to the scheduler: adding data to a data visualization and processing user input to change zoom levels. Putting aside the accumulation of latency between nested function calls, a frame doesn't get rendered for 200ms. How can I ensure that frames aren't dropped?

I think the answer depends on exactly what's running between frames. A few notes:

1. The intersection of rendering and task scheduling is complicated and is an active area of research in Chromium (e.g. some recent work). Browsers currently have a lot of freedom over when to render, which isn't something we're looking to change with postTask. But we also want to help address these challenges in some way through scheduling APIs, just probably not in V0. There's a GitHub issue that you can track that has more details, and adding your use cases to that would be helpful (if postTask is the problem in your example).
2. In Chromium's implementation of postTask (not required by the spec), it should always choose rendering over { priority: 'background' }. If it's not, then maybe your input handling is causing the frame drops?
3. A follow-up to (2), behavior with continuous inputs (mouse-moves, scroll wheel) is known to be different when devtools is open (see this recent bug). Normally these are rAF-aligned and run at the highest priority. I'm not sure if this is coming into play with your example, but it could be since you mentioned input handling is involved.

[Stefan Novak]

Thanks for taking the time to write an insightful response! I appreciate the references to on-going work and I look forward to following those developments.

Cheers!

--

Stefan Novak