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.