Intent to Ship: Align Timers (including DOM timers) at 125 Hz

[Etienne Pierre-doray]

Contact emails

etie...@chromium.org

Specification

https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html

Design docs

https://docs.google.com/document/d/1OjZoHNvn_vz6bhyww68B_KZBi6_s5arT8xMupuNEnDM/edit

Summary

Run all timers (with a few exceptions) with a non-zero delay on a regular 8ms aligned wake up (125 Hz), instead of as soon as their delay has passed. This affects DOM timers; On foreground pages, run DOM timers with a non-zero delay on a regular 8ms aligned wake up, instead of as soon as their delay has passed. On background pages, DOM timers already run on a regular 1s aligned wake up (1 Hz), or even less frequently after 5 minutes.

Blink component

Blink>Scheduling

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This feature changes the behavior of an existing API in a way that is spec-compliant (the spec says "Optionally, wait a further implementation-defined length of time", ref.: https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#run-steps-after-a-timeout). Content that relies on precise timing for DOM Timers may stop working properly in Chromium with this feature. The risk is mitigated by delaying DOM Timers by at most 8 ms. Content that cannot support a 8 ms delay would probably be better served by alternative APIs described at https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds. Due to the significant battery savings that come with this feature, we expect that most browsers will decide to implement it after some time.

Gecko: No signal

WebKit: Neutral (https://github.com/WebKit/standards-positions/issues/44) Note that WebKit already has some DOM timer alignment logic (see Page::updateDOMTimerAlignmentInterval()), which depends on low power mode, page visibility and user interaction. It's also possible that there's some alignment logic at the platform level which is designed to reduce CPU wakeups.

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Debuggability

This changes the behavior of an existing API. No new debugging support is added.

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?

No

DevTrial instructions

https://github.com/eti-p-doray/align-wakeups/blob/main/HOWTO.md

Flag name

align-wakeups

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1153139

Estimated milestones

DevTrial on desktop

105

DevTrial on Android

105

Chrome on desktop

107

Chrome on Android

107

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

This feature changes the behavior of an existing API in a way that is spec-compliant

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5680188671655936

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsaQA8iqxdxNEh1PkBCzPFSsSSmZ72Jgmev-bdwenG6DrQ%40mail.gmail.com

Related to this discussion; we're now at step (3), the feature has been enabled at 100% on beta for almost 3 weeks, and M107 will soon roll out to stable.

Enabling the feature by default triggered crbug.com/1368989 (fuschia only, addressed), although this was unrelated to the web platform and DOM timers. No other issues were reported AFAIK.

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

On 10/19/22 8:05 PM, Etienne Pierre-doray wrote:

Contact emails

etie...@chromium.org

Specification

https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html

Design docs

https://docs.google.com/document/d/1OjZoHNvn_vz6bhyww68B_KZBi6_s5arT8xMupuNEnDM/edit

Summary

Run all timers (with a few exceptions) with a non-zero delay on a regular 8ms aligned wake up (125 Hz), instead of as soon as their delay has passed. This affects DOM timers; On foreground pages, run DOM timers with a non-zero delay on a regular 8ms aligned wake up, instead of as soon as their delay has passed. On background pages, DOM timers already run on a regular 1s aligned wake up (1 Hz), or even less frequently after 5 minutes.

Blink component

Blink>Scheduling

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This feature changes the behavior of an existing API in a way that is spec-compliant (the spec says "Optionally, wait a further implementation-defined length of time", ref.: https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#run-steps-after-a-timeout). Content that relies on precise timing for DOM Timers may stop working properly in Chromium with this feature. The risk is mitigated by delaying DOM Timers by at most 8 ms. Content that cannot support a 8 ms delay would probably be better served by alternative APIs described at https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds. Due to the significant battery savings that come with this feature, we expect that most browsers will decide to implement it after some time.

Gecko: No signal

Have we asked Mozilla for a signal?

--
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/CALoDvsbKunY1%3DzbQ38HxKa3kyEvZjNB4ekqZLGmyYsM0uQPB1w%40mail.gmail.com.

[Olli Pettay]

On 10/20/22 18:23, Mike Taylor wrote:
> On 10/19/22 8:05 PM, Etienne Pierre-doray wrote:
>>
>>
>> Contact emails
>>
>> etie...@chromium.org
>>
>>
>> Specification
>>
>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
>>
>>
>> Design docs
>>
>>
>> https://docs.google.com/document/d/1OjZoHNvn_vz6bhyww68B_KZBi6_s5arT8xMupuNEnDM/edit
>>
>>
>> Summary
>>
>> Run all timers (with a few exceptions) with a non-zero delay on a regular 8ms aligned wake up (125 Hz), instead of as soon as their delay has
>> passed. This affects DOM timers; On foreground pages, run DOM timers with a non-zero delay on a regular 8ms aligned wake up, instead of as soon as
>> their delay has passed. On background pages, DOM timers already run on a regular 1s aligned wake up (1 Hz), or even less frequently after 5 minutes.
>>
>>
>>
>> Blink component
>>

>> Blink>Scheduling <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScheduling>

>>
>>
>> TAG review
>>
>>
>>
>> TAG review status
>>
>> Not applicable
>>
>>
>> Risks
>>
>>
>>
>> Interoperability and Compatibility
>>
>> This feature changes the behavior of an existing API in a way that is spec-compliant (the spec says "Optionally, wait a further
>> implementation-defined length of time", ref.: https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#run-steps-after-a-timeout).
>> Content that relies on precise timing for DOM Timers may stop working properly in Chromium with this feature. The risk is mitigated by delaying DOM
>> Timers by at most 8 ms. Content that cannot support a 8 ms delay would probably be better served by alternative APIs described at
>> https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds. Due to the significant battery savings that come with this feature, we
>> expect that most browsers will decide to implement it after some time.
>>
>>
>>

>> /Gecko/: No signal

>
> Have we asked Mozilla for a signal?
>

I don't think so. I could say we're interested in trying to reduce wake-ups, but it is unclear how this 125Hz works in scenarios like when one has a
very high refresh rate monitor (talking about monitors >250Hz). Browsers already struggle a bit in those cases in various ways. My gut feeling is that
in those cases we'd rather try to schedule short timer runs between each rAF than every 8ms.


-Olli





>>
>> /WebKit/: Neutral (https://github.com/WebKit/standards-positions/issues/44) Note that WebKit already has some DOM timer alignment logic (see

>> Page::updateDOMTimerAlignmentInterval()), which depends on low power mode, page visibility and user interaction. It's also possible that there's
>> some alignment logic at the platform level which is designed to reduce CPU wakeups.
>>

>> /Web developers/: No signals
>>
>> /Other signals/:

>>
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
>>
>>
>>
>> Debuggability
>>
>> This changes the behavior of an existing API. No new debugging support is added.
>>
>>
>>
>> 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?

>>
>> No
>>
>>
>> DevTrial instructions
>>
>> https://github.com/eti-p-doray/align-wakeups/blob/main/HOWTO.md
>>
>>
>> Flag name
>>
>> align-wakeups
>>
>>
>> Requires code in //chrome?
>>
>> False
>>
>>
>> Tracking bug
>>
>> https://crbug.com/1153139
>>
>>
>>
>> Estimated milestones
>>
>>
>> DevTrial on desktop 105
>>
>> DevTrial on Android 105
>>
>> Chrome on desktop 107
>>
>>
>> Chrome on Android 107
>>
>>
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in
>> the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API
>> in a non-backward-compatible way).
>>
>> This feature changes the behavior of an existing API in a way that is spec-compliant
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5680188671655936
>>
>>
>> Links to previous Intent discussions
>>
>> Intent to Experiment:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsaQA8iqxdxNEh1PkBCzPFSsSSmZ72Jgmev-bdwenG6DrQ%40mail.gmail.com

>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsaQA8iqxdxNEh1PkBCz...@mail.gmail.com>
>>
>> Related to this discussion <https://groups.google.com/a/chromium.org/g/blink-dev/c/POCUbyCqnrc/m/MfPXQmm8AgAJ>; we're now at step (3), the feature

>> has been enabled at 100% on beta for almost 3 weeks, and M107 will soon roll out to stable.

>> Enabling the feature by default triggered crbug.com/1368989 <http://crbug.com/1368989> (fuschia only, addressed), although this was unrelated to the

>> web platform and DOM timers. No other issues were reported AFAIK.
>>
>>

>> This intent message was generated by Chrome Platform Status <https://chromestatus.com/>.

>> --
>> 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/CALoDvsbKunY1%3DzbQ38HxKa3kyEvZjNB4ekqZLGmyYsM0uQPB1w%40mail.gmail.com

>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsbKunY1%3DzbQ38HxKa3kyEvZjNB4ekqZLGmyYsM0uQPB1w%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
>
> --
> 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

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/75e9dead-5f02-4787-4e40-f91540f6bdb2%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/75e9dead-5f02-4787-4e40-f91540f6bdb2%40chromium.org?utm_medium=email&utm_source=footer>.

[Etienne Pierre-doray]

Have we asked Mozilla for a signal?

I haven't asked for a signal. I can ask but this feels N/A; this change is Web facing but remains spec-compliant, and I don't think we want to change the spec or browsers need to align. Quoting a reply from Webkit "even if there were a web specification, and even if a browser faithfully tried to implement it, the web programmer would still not get the specified behavior on most hardware and operating systems most of the time."

I should correct myself, asking for a position form WebKit actually yielded an invalid signal "The issue is not about a specification".

[Mike Taylor]

On 10/20/22 11:39 AM, Olli Pettay wrote:
> On 10/20/22 18:23, Mike Taylor wrote:
>> On 10/19/22 8:05 PM, Etienne Pierre-doray wrote:
>>> /Gecko/: No signal
>>
>> Have we asked Mozilla for a signal?
>>
>
> I don't think so. I could say we're interested in trying to reduce
> wake-ups, but it is unclear how this 125Hz works in scenarios like
> when one has a very high refresh rate monitor (talking about monitors
> >250Hz). Browsers already struggle a bit in those cases in various
> ways. My gut feeling is that in those cases we'd rather try to
> schedule short timer runs between each rAF than every 8ms.

Thanks for the input Olli (I just found your reply in my spam folder
(?), also I've apparently won the lottery, so that's cool).

[Mike Taylor]

Thanks Etienne.

LGTM1 to ship - good luck with the rollout.

[Mike West]

LGTM2.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/18082bde-90c1-1f9c-5652-80857ff9e983%40chromium.org.

[Yoav Weiss]

LGTM3 for a careful rollout

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DebVsnnUpr%3D7snhsBMsvsEL9Nv3-Rph3ncWEsuXBch4%3DQ%40mail.gmail.com.