On the animation question, 8ms coalescence should service up to 120hz, but high-framerate apps aren't likely to be doing timer-based animation. I'm less worries about that than I am about other, less understood impacts.
Strong +1 on trying to understand everything we can about content that might be affected, and reaching out to developers and other vendors who might have insight into workloads that rely on the current behavior. That said, I'm also supportive of trying this in Canary/Dev ASAP (without rolling to Beta) to try to get that data. Best, Alex On Wednesday, August 3, 2022 at 8:27:45 PM UTC-7 Yoav Weiss wrote: > On Wed, Aug 3, 2022 at 7:07 PM Etienne Pierre-doray <etien...@chromium.org> > wrote: > >> What's the plan for monitoring potential breakage? Looking at incoming >>> bugs? >> >> Yes, there's been a few breakage on earlier channel (all addressed as of >> now). This one was related to DOM timer: >> https://buganizer.corp.google.com/issues/220682826 >> > > For folks outside of Google, the bug describes a site that relied on timer > accuracy to schedule tasks, and saw a degradation in their performance > metrics. The site in question then fixed it by moving away from those > methods. (I hope I'm capturing that correctly. I only skimmed through the > issue so please correct me if I got it wrong) > > I suspect many non-Google properties run similar code, and would similarly > be surprised by this change. e.g. I know that many JS driven animations > used to rely on timers, and I'm not sure that's no longer the case. > Similarly, performance measurements that rely on timer accuracy as a proxy > for "CPU busyness" are common. > > >> Might be worthwhile to ask: https://bit.ly/blink-signals >> >> There's anecdotal evidence that Webkit is aligning timers at 10ms; all I >> could find re. DOM timers is this >> <https://sourcegraph.com/github.com/WebKit/WebKit/-/commit/9583464b465af2976839791deff41cbe6495f6ca?visible=6> >> throttling >> at 30Hz in low power mode. >> Does https://bit.ly/blink-signals apply even if this chromestatus >> doesn't change the spec? >> > > The web-exposed behavior is changing here, with potential compatibility > and interoperability implications. So even if the spec allows for that, I > think it's worthwhile to ask other vendors for their opinions on this. > > >> >> Question: What about APIs that have no proper flow control support, e.g. >>> WebSocket? They rely on (ab)use of setTimeout to avoid writing too much >>> into the underlying buffer. I wouldn't consider a 1s flow disruption delay >>> to be acceptable for this use case, not even in the background. Are there >>> any plans to prevent such issues? >>> >> Although that was meant for another proposal, this blog post >> <https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds> >> >> suggests an alternative to some setTimeout abuses. >> Note that this proposal only concerns the 8ms delay. The 1s throttling >> was done in this previous chromestatus >> <https://chromestatus.com/feature/4718288976216064> for background pages >> and shipped in M86. >> >> On Wed, Aug 3, 2022 at 11:42 AM Lennart Grahl <lennart.gr...@gmail.com> >> wrote: >> >>> Question: What about APIs that have no proper flow control support, e.g. >>> WebSocket? They rely on (ab)use of setTimeout to avoid writing too much >>> into the underlying buffer. I wouldn't consider a 1s flow disruption delay >>> to be acceptable for this use case, not even in the background. Are there >>> any plans to prevent such issues? >>> >>> On Wednesday, 3 August 2022 at 15:50:48 UTC+2 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/CALoDvsZoosJps02cN-3885ubOggjk_JkH4ffUZosQoTWFrNWuQ%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsZoosJps02cN-3885ubOggjk_JkH4ffUZosQoTWFrNWuQ%40mail.gmail.com?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/501212b5-0dd2-4f7c-8cd7-17e2c37cba9fn%40chromium.org.
