Intent to Implement and Ship: High priority for one-off input events

[Alexander Timin]

Contact emails

alt...@chromium.org, schedu...@chromium.org

Design doc

Link

Summary

Move one-off input events from compositor task queue to a separate input task queue and assign a constant highest priority to the input task queue instead of relying on scheduling heuristics. Note that the old scheduling heuristics are still used for non-vsync-aligned input.

Demo

Results from Beta channel (sorry, Googlers only).

tl;dr: 8% reduction in 99%-th percentile of touch start latency on Android.

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

Yes.

Risks

Interoperability and Compatibility

Very low, but we'll keep an eye on bug reports from sites with complex touchstart handlers.

Edge: N/A

Firefox: N/A

Safari: N/A

Web developers: N/A

Ergonomics

This is a direct improvement to Chrome's ergonomics.

Activation

No activation required.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

N/A

Entry on the feature dashboard

N/A, internal change in scheduling logic which is not directly user-visible.

[Yoav Weiss]

On Wed, Jun 13, 2018 at 7:13 PM Alexander Timin <alt...@chromium.org> wrote:

Contact emails

alt...@chromium.org, schedu...@chromium.org

Design doc

Link

Summary

Move one-off input events from compositor task queue to a separate input task queue and assign a constant highest priority to the input task queue instead of relying on scheduling heuristics. Note that the old scheduling heuristics are still used for non-vsync-aligned input.

Demo

Results from Beta channel (sorry, Googlers only).

tl;dr: 8% reduction in 99%-th percentile of touch start latency on Android.

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

Yes.

Risks

Interoperability and Compatibility

Very low, but we'll keep an eye on bug reports from sites with complex touchstart handlers.

Will this change be web observable? Or will it just kick off things faster than they used to?

  

Edge: N/A

Firefox: N/A

Safari: N/A

Web developers: N/A

Ergonomics

This is a direct improvement to Chrome's ergonomics.

Activation

No activation required.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

N/A

Entry on the feature dashboard

N/A, internal change in scheduling logic which is not directly user-visible.

--
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/CALHg4nnrA6o2mSHcpfc%3D2X3u4wOE%3DR6GDoAAs_JXs9S2D6aSjw%40mail.gmail.com.

[Alexander Timin]

Generally it should just kick things off faster, but there is a low probability of this being web observable via ordering of touchhandlers and requestAnimationFrame callbacks on specifically crafted pages. I don't think that it would matter in real life, though.

[Daniel Bratell]

The HTML spec already has the concept of different task sources where ordering is only guaranteed within the task source. Will this event jump ahead of similar events?

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALHg4nmp6xP6f-VxtsyndddKEBvqwOy3yievYvAqkWX31ga-3w%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Alexander Timin]

On Wed, 13 Jun 2018 at 22:15, Daniel Bratell <bra...@opera.com> wrote:

The HTML spec already has the concept of different task sources where ordering is only guaranteed within the task source. Will this event jump ahead of similar events?

No, this change is safe from spec & task sources point of view.

[Daniel Bratell]

LGTM1 (though this may also qualify as a non-dev-observable change). Looking forward to better responsiveness at overloaded phones!

/Daniel

[Yoav Weiss]

LGTM2 with a similar caveat - I'm not sure LGTMs are even required here.

[Philip Jägenstedt]

LGTM3, even though relative order of input events and some other events may change, as long as the order within each "task queue" is preserved it's worth a try. There still could be a compat risk, of course.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjimS8pSRvsyZOs5d4vjk2bK-EsmCDtqpHSXEoBWXiL9Q%40mail.gmail.com.