I don't love this at all. A more flexible batching/coalescing that *can* 
batch/coalesce when it makes sense, but which preserves the desired/asked 
for wake-ups when they are all alone & there's nothing to coalesce to would 
be far more reasonable/kind. This feels like it applies a huge cudgel to 
all users because some users use too many wakeups. I think most of the 
expected power savings can be gotten for the bad users, without such a vast 
& sad negative impact for the responsible users. Linux gained a similar 
"Tickless" kernel support capability in 2.6.6, May 2004, and this feels 
like a significant reversion to a state of tech far predating that basic 
innovation. I cannot support the sacrifices made here. Please do a little 
more work on this to only impact bad users/places where this might help; 
not everyone.

Couple other details:

Can authors still expect long term guarantees? If I request 10ms 
setInterval, and then write a counter that counts to a thousand, will ~10s 
have passed to get there? Folks doing media-timing rely on their 
setIntervals being wall-clock stable-ish; does this significant change 
threaten that?

125Hz is going to serve up tick at least once per frame up to 120hHz. But 
the amount of available execution time before frame is going to phase in & 
out of sync (at almost any display rate frequency) such that there are 
times there is plenty of execution time, & times when it is happening right 
near where the frame tick would be. This spec seems like might increases 
the probability of jank occurring at regular intervals.

In general I think this tick rate would have been a good target for 2015, 
but that we are hoping to build more snappy & responsive systems. 250Hz 
would be a better tick rate, coming with 4ms potential delays rather than 
8ms.
On Wednesday, August 3, 2022 at 9:50:48 AM UTC-4 Etienne Pierre-doray wrote:

> etie...@chromium.org
>
> ExplainerNone
>
> 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 affect 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 
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScheduling>
>
> 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, and by disabling the feature when WebRTC has 
> active connections in the process. 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*: No signal
>
> *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?
>
>
>
> Goals for experimentation
>
> Gain insight on potential compatibility issues and evaluate impact on 
> guardian metrics (page load, latency).
>
>
> Reason this experiment is being extended
>
>
>
> Ongoing technical constraints
>
>
>
> 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 namealign-wakeups
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1153139
>
> Estimated milestones
> OriginTrial desktop last 105
> OriginTrial desktop first 105
> DevTrial on desktop 105
> OriginTrial Android last 105
> OriginTrial Android first 105
> DevTrial on Android 105
> OriginTrial webView last 105
> OriginTrial webView first 105We plan to do a 1% Stable experiment for 
> M105 stable.
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5680188671655936
>

-- 
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/4c0bf240-c577-40ad-91a6-bb2991444ae6n%40chromium.org.

Reply via email to