etien...@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/CALoDvsaQA8iqxdxNEh1PkBCzPFSsSSmZ72Jgmev-bdwenG6DrQ%40mail.gmail.com.
