Re: [blink-dev] Intent to Ship: Align Timers (including DOM timers) at 125 Hz

2022-10-25 Thread Yoav Weiss 
LGTM3 for a careful rollout

On Tue, Oct 25, 2022 at 10:36 AM Mike West  wrote:

> LGTM2.
>
> -mike
>
>
> On Mon, Oct 24, 2022 at 4:59 PM Mike Taylor 
> wrote:
>
>> Thanks Etienne.
>>
>> LGTM1 to ship - good luck with the rollout.
>>
>> On 10/20/22 12:18 PM, Etienne Pierre-doray wrote:
>>
>> 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".
>>
>> On Thu, Oct 20, 2022 at 11:23 AM Mike Taylor 
>> wrote:
>>
>>> On 10/19/22 8:05 PM, Etienne Pierre-doray wrote:
>>>
>>> Contact emails etien...@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?
>>>
>>>
>>> *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

Re: [blink-dev] Intent to Ship: Align Timers (including DOM timers) at 125 Hz

2022-10-25 Thread Mike West 
LGTM2.

-mike


On Mon, Oct 24, 2022 at 4:59 PM Mike Taylor  wrote:

> Thanks Etienne.
>
> LGTM1 to ship - good luck with the rollout.
>
> On 10/20/22 12:18 PM, Etienne Pierre-doray wrote:
>
> 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".
>
> On Thu, Oct 20, 2022 at 11:23 AM Mike Taylor 
> wrote:
>
>> On 10/19/22 8:05 PM, Etienne Pierre-doray wrote:
>>
>> Contact emails etien...@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?
>>
>>
>> *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
>>

Re: [blink-dev] Intent to Ship: Align Timers (including DOM timers) at 125 Hz

2022-10-24 Thread Mike Taylor 

Thanks Etienne.

LGTM1 to ship - good luck with the rollout.

On 10/20/22 12:18 PM, Etienne Pierre-doray wrote:


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


On Thu, Oct 20, 2022 at 11:23 AM Mike Taylor  
wrote:


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



Contact emails

etien...@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?



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

Re: [blink-dev] Intent to Ship: Align Timers (including DOM timers) at 125 Hz

2022-10-24 Thread 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).


--
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/174ac3c9-d265-5a97-2353-05d0424a5496%40chromium.org.

Re: [blink-dev] Intent to Ship: Align Timers (including DOM timers) at 125 Hz

2022-10-20 Thread 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".

On Thu, Oct 20, 2022 at 11:23 AM Mike Taylor  wrote:

> On 10/19/22 8:05 PM, Etienne Pierre-doray wrote:
>
> Contact emails etien...@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?
>
>
> *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

Re: [blink-dev] Intent to Ship: Align Timers (including DOM timers) at 125 Hz

2022-10-20 Thread Olli Pettay 

On 10/20/22 18:23, Mike Taylor wrote:

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



Contact emails

etien...@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?




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 
?

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

Re: [blink-dev] Intent to Ship: Align Timers (including DOM timers) at 125 Hz

2022-10-20 Thread Mike Taylor 

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



Contact emails

etien...@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?



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

--
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+unsubscr...@chromium.org.
To view this discussion on

[blink-dev] Intent to Ship: Align Timers (including DOM timers) at 125 Hz

2022-10-19 Thread Etienne Pierre-doray 
Contact emailsetien...@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 componentBlink>Scheduling


TAG review

TAG review statusNot 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 namealign-wakeups

Requires code in //chrome?False

Tracking bughttps://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 discussionsIntent 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
.

-- 
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+unsubscr...@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.