Intent to Ship: isInputPending
Andrew Comminos
Contact emails
acom...@fb.com, pani...@chromium.org, tdre...@chromium.org
Explainer
https://github.com/WICG/is-input-pending
Specification
https://wicg.github.io/is-input-pending/
Design docs
https://github.com/WICG/is-input-pending
Summary
This API enables developers to query for the presence of pending input events while running JavaScript. This enables them to respond immediately to user input by yielding, while being able to complete their work as fast as possible.
Blink component
TAG review
https://github.com/w3ctag/design-reviews/issues/475
TAG review status
Issues addressed
Risks
Interoperability and Compatibility
Interoperability risk: Medium. If other browsers do not implement this API, then a similar (albeit less performant) outcome can be achieved by yielding more often after checking for the presence of navigator.scheduling.isInputPending. This API has been discussed at length at TPAC 2018, TPAC 2019, and in Web Performance Working Group calls.
Compatibility risk: Low. Existing behaviour is unaffected. The primary mechanism through which compatibility risk could be introduced is through the addition of new input event types later down the line, in which case the function may return true more or less often than expected. We attempt to mitigate this by defining a semantic dichotomy of events (continuous and discrete, rather than allow filtering on a per-event basis).
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/155)
WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2020-September/031390.html)
Web developers: Strongly positive
-
A Google ads team ran an experiment demonstrating they could yield 15% of the time on certain domains with an average input delay improvement of 100ms. They stated that the isInputPending latency improvement has clear UX benefit.
-
The Google Slides team was able to see a substantial improvement in render time (about 25%) of the left-hand-side filmstrip UI for complex content by not yielding (which is only possible with isInputPending, or else there would be unacceptable input delay).
-
Facebook was able to reduce event latency at p95 by 100ms by integrating isInputPending in an origin trial, while retaining their scheduler’s throughput.
Activation
This API will typically be used by framework libraries, such as React with concurrent mode (although any site that manages its own work queue may benefit). React plans to integrate isInputPending into their concurrent mode scheduler immediately. For web applications that do not use frameworks leveraging isInputPending yet frequently perform long tasks, they may benefit from additional outreach.
Security
Implementers must take care to ensure that frames may not detect input events from other cross-origin frames. In Blink, this is achieved by performing hit testing on the compositor side for cross-origin frames within-process, and via viz for OOPIFs.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Yes (https://wpt.fyi/results/is-input-pending)
Tracking bug
https://bugs.chromium.org/p/chromium/issues/approval?id=930987
Sample links
https://wicg.github.io/is-input-pending/#examples-of-usage
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5719830432841728
Links to previous Intent discussions
Intent to Prototype: https://groups.google.com/a/chromium.org/d/msg/blink-dev/eLq8t56CbaQ/KdbOY7ZHCwAJ
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msg/blink-dev/ItkbDBevOrs/yFffQlqTBQAJ
Yoav Weiss
Contact emails
acom...@fb.com, pani...@chromium.org, tdre...@chromium.org
Explainer
https://github.com/WICG/is-input-pending
Specification
https://wicg.github.io/is-input-pending/
Design docs
https://github.com/WICG/is-input-pending
Summary
This API enables developers to query for the presence of pending input events while running JavaScript. This enables them to respond immediately to user input by yielding, while being able to complete their work as fast as possible.
Blink component
TAG review
https://github.com/w3ctag/design-reviews/issues/475
TAG review status
Issues addressed
Risks
Interoperability and Compatibility
Interoperability risk: Medium. If other browsers do not implement this API, then a similar (albeit less performant) outcome can be achieved by yielding more often after checking for the presence of navigator.scheduling.isInputPending. This API has been discussed at length at TPAC 2018, TPAC 2019, and in Web Performance Working Group calls.
Compatibility risk: Low. Existing behaviour is unaffected. The primary mechanism through which compatibility risk could be introduced is through the addition of new input event types later down the line, in which case the function may return true more or less often than expected. We attempt to mitigate this by defining a semantic dichotomy of events (continuous and discrete, rather than allow filtering on a per-event basis).
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/155)
WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2020-September/031390.html)
Web developers: Strongly positive
A Google ads team ran an experiment demonstrating they could yield 15% of the time on certain domains with an average input delay improvement of 100ms. They stated that the isInputPending latency improvement has clear UX benefit.
The Google Slides team was able to see a substantial improvement in render time (about 25%) of the left-hand-side filmstrip UI for complex content by not yielding (which is only possible with isInputPending, or else there would be unacceptable input delay).
Facebook was able to reduce event latency at p95 by 100ms by integrating isInputPending in an origin trial, while retaining their scheduler’s throughput.
Activation
This API will typically be used by framework libraries, such as React with concurrent mode (although any site that manages its own work queue may benefit). React plans to integrate isInputPending into their concurrent mode scheduler immediately. For web applications that do not use frameworks leveraging isInputPending yet frequently perform long tasks, they may benefit from additional outreach.
Security
Implementers must take care to ensure that frames may not detect input events from other cross-origin frames. In Blink, this is achieved by performing hit testing on the compositor side for cross-origin frames within-process, and via viz for OOPIFs.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Yes (https://wpt.fyi/results/is-input-pending)
Tracking bug
https://bugs.chromium.org/p/chromium/issues/approval?id=930987
Sample links
https://wicg.github.io/is-input-pending/#examples-of-usage
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5719830432841728
Links to previous Intent discussions
Intent to Prototype: https://groups.google.com/a/chromium.org/d/msg/blink-dev/eLq8t56CbaQ/KdbOY7ZHCwAJ
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msg/blink-dev/ItkbDBevOrs/yFffQlqTBQAJ
--
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/BYAPR15MB2728DBE16ED8A83933E33C7EC73F0%40BYAPR15MB2728.namprd15.prod.outlook.com.
matan genish
Philip Walton
Kenneth Rohde Christiansen
https://www.mail-archive.com/webki...@lists.webkit.org/msg29681.html
--
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone +45 4294 9458 ﹆﹆﹆
Daniel Bratell
but on the other hand it seems like several applications have been able
to achieve substantial improvements using the isInputPending API.
From that point of view it is either isInputPending or some other
change that can result in similar improvements. I see that many people
have talked about this a lot, but since I'm not one of those, could
someone (acomminos?) recap the alternative approaches?
/Daniel
Andrew Comminos
On 9/24/20 12:49 PM, Daniel Bratell wrote:
> I think Apple's response is reasonable from a theoretical point of view,
> but on the other hand it seems like several applications have been able
> to achieve substantial improvements using the isInputPending API.
>
> From that point of view it is either isInputPending or some other
> change that can result in similar improvements. I see that many people
> have talked about this a lot, but since I'm not one of those, could
> someone (acomminos?) recap the alternative approaches?
>
> /Daniel
frequently, which can cause a significant throughput hit when performing
user-blocking work. This is the result of the scheduler being starved in
favour of lower-priority work by the UA or other script/frames, as well
as inherent task processing overhead.
A high level overview of the problem space is available here:
https://github.com/WICG/is-input-pending/blob/master/README.md#the-problem
> On 2020-09-24 18:46, Kenneth Rohde Christiansen wrote:
>> Apple is skeptical of this new API as stated on webkit-dev:
>>
>> On Thu, Sep 24, 2020 at 5:55 PM 'Philip Walton' via blink-dev
>> <blin...@chromium.org> wrote:
>>> We might want to consider holding off on shipping this until we
>>> resolve how this API interacts with the Long Tasks API. Specifically
>>> this issue:
>>> https://github.com/WICG/is-input-pending/issues/37
>>>
>>> Since my understanding is this API is planned to be included in React
>>> (and possibly other frameworks), the users of those frameworks might
>>> update to the latest version and test their performance in
>>> Lighthouse—only to see a regression due to the increased lengths of
>>> Long Tasks.
activation energy is strong enough to require blocking on -- for the
React case you describe, developers would have to switch to concurrent
mode to leverage this (which is not available in a stable release yet).
Additionally, these numbers will be disrupted (positively) when moving
to concurrent mode regardless.
It's worth noting that frameworks with schedulers can't do _all_ of
their work in long tasks leveraging isInputPending, especially when they
want to paint responsively. It's typically beneficial during early load
when user input would change the result of paint.
>>> On Tuesday, September 22, 2020 at 10:31:26 AM UTC-7 matan genish wrote:
>>>> Really looking forward for this new API.
>>>> We have few ideas on how to leverage it for Excel Online.
>>>>
>>>> On Monday, September 21, 2020 at 10:22:57 AM UTC+3 yo...@yoav.ws wrote:
>>>>> Thanks for working on this! I believe this API can unlock
>>>>> significant performance benefits.
>>>>>
>>>>> On Fri, Sep 18, 2020 at 9:34 PM 'Andrew Comminos' via blink-dev
>>>>> <blin...@chromium.org> wrote:
>>>>>> Contact emails
>>>>>>
>>>>>> acom...@fb.com, pani...@chromium.org, tdre...@chromium.org
>>>>>>
>>>>>>
>>>>>> Explainer
>>>>>>
>>>>>> https://github.com/WICG/is-input-pending
>>>>>>
>>>>>>
>>>>>> Specification
>>>>>>
those issues.
We arrived at a minor API change after looking more closely at #35.
However, the solution proposed in #15 constrains the API with the burden
of promise allocation (which, as measured, can be quite expensive in a
hot loop). I believe the concerns in #15 would be better addressed with
a separate yielding API, as discussed in the issue.
>>>>>> Security
>>>>>>
>>>>>> Implementers must take care to ensure that frames may not detect
>>>>>> input events from other cross-origin frames. In Blink, this is
>>>>>> achieved by performing hit testing on the compositor side for
>>>>>> cross-origin frames within-process, and via viz for OOPIFs.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Will this feature be supported on all six Blink platforms
>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
>>>>>>
>>>>>> Yes
>>>>>>
>>>>>>
>>>>>> Is this feature fully tested by web-platform-tests?
>>>>>>
>>>>>> Yes
>>>>>> )
>>>>>>
>>>>>>
>>>>>> Tracking bug
>>>>>>
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.chromium.org_p_chromium_issues_approval-3Fid-3D930987&d=DwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=f4IqI-T64EhPzlPNDufP_w&m=G4UeKHarmKWvOL-jGqn6gyitV7KEb72pezmk4w95TlQ&s=Gha8CTMM4S4iDosTNKibyyKhdZLjKm8cBN5MW2J1g_w&e=
>>>>>>
>>>>>>
>>>>>> Sample links
>>>>>>
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__wicg.github.io_is-2Dinput-2Dpending_-23examples-2Dof-2Dusage&d=DwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=f4IqI-T64EhPzlPNDufP_w&m=G4UeKHarmKWvOL-jGqn6gyitV7KEb72pezmk4w95TlQ&s=YlZfXWy0GPE4RWpjstlWpTkUneeufmrEr6V4IN1g2oA&e=
>>>>>>
>>>>>> Link to entry on the Chrome Platform Status
>>>>>>
>>>>>>
>>>>>> Links to previous Intent discussions
>>>>>>
>>>>>> Intent to Prototype:
>>>>>>
>>>>>> Intent to Experiment:
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_a_chromium.org_d_msg_blink-2Ddev_ItkbDBevOrs_yFffQlqTBQAJ&d=DwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=f4IqI-T64EhPzlPNDufP_w&m=G4UeKHarmKWvOL-jGqn6gyitV7KEb72pezmk4w95TlQ&s=xoLz_YzejhQ8gIwnGXhL2s9FxBdgT-Y9f4TFlZ9docw&e=
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>> .
>>> 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
>>> .
>>
>>
>
Yoav Weiss
- Regarding issue 15:
- The API doesn't currently allow yielding code to *know* that the reason for which it's yielding (e.g. specific pending input) is done
- At the same time, applications already opportunistically yield today, assuming that the browser would handle high priority work before giving them back the main thread. The API would enable such apps to yield less when it's not necessary, resulting in significant performance benefits
- `scheduler.yield()` is likely to be a complementary API to this, and can assist in cases where the caller needs to know the input was addressed. At the same time, it's not yet clear what exact shape it would take and when it would be ready.
- Regarding issue 37, the intended use of the API should not incur more long tasks, as apps are expected to yield before long tasks occur. As such, integration with Long Tasks seem less critical, and not a blocker. (as RUM providers and synthetic testing tools should still warn developers of code that triggers LTs, even if it's calling isInputPending).
- Issue 35 was addressed.
--
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/141dca84-024a-75d6-67cf-a3a6e090464f%40fb.com.
Daniel Bratell
LGTM2
