On Tue, Sep 6, 2022 at 3:26 PM Morgaine (de la faye) <rekt...@gmail.com> wrote:
> 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. > Can you give an example where it's important to have greater precision? Even now, timers are not guaranteed to be serviced exactly when they expire -- a browser is not a real-time OS -- so what is actually lost? I'm not sure what "media timing" is exactly, but if you need precise elapsed time, then performance.now() is the recommended approach. As for aligning with display refresh rate: a timer will never do better than requestAnimationFrame in this regard. > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4c0bf240-c577-40ad-91a6-bb2991444ae6n%40chromium.org?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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHOQ7J-v3cNfTq0XoOLoGe8%3Dz4bhHkjKbyqH2uLEm%2BJfkrYSgg%40mail.gmail.com.
