> > 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) > As a solution, we ended up opting-out any DOM timer from alignment whenever there's an active WebRTC connection in the process (as a proxy for video conferencing), so similar videoconferencing patterns in non-Google sites won't be affected by the experiment. That being said, there exists an alternative to setTimeout() for this use case, MediaStreamTrackProcessor().readable.
> I know that many JS driven animations used to rely on timers, and I'm not > sure that's no longer the case. > Like Alex said, animations driven by setTimeout() aren't significantly affected by a 8ms alignment because the typical frame rate (16ms) is aligned on the same boundary (although the well-known alternative rAF is preferred). Similarly, performance measurements that rely on timer accuracy as a proxy > for "CPU busyness" are common. Do you have a concrete example to look at? I would like understand the use case to identify efficient alternatives similar to what we did in timer-throttling-in-chrome-88 <https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds> . Considering Windows resolution <https://source.chromium.org/chromium/chromium/src/+/main:base/time/time_win.cc;l=137?q=windows%20timeticks&ss=chromium> is ~16ms for delays > 32ms, I wouldn't expect this to be very reliable in the first place; in fact, any setTimeout() with a delay >32ms isn't significantly affected by this proposal. Might be worthwhile to ask: https://bit.ly/blink-signals Issue created here <https://github.com/WebKit/standards-positions/issues/44> . That said, I'm also supportive of trying this in Canary/Dev ASAP (without > rolling to Beta) to try to get that data. > For context, we already experimented with AlignWakeUps on Canary/Dev a few times and on Beta in June (~4 weeks). Notably, the experiment showed a substantial reduction (improvement) of Chrome Energy Impact. Another issues that was surfaced (and fixed) during this experiment crbug.com/1340677 (which is not related to DOM timers). One main goal of experimenting on stable is to get a statistically significant and reliable signal for battery discharge. With this in mind, there's no added value for us in experimenting on pre-stable anymore (which typically doesn't produce reliable enough data) and we would like to move up to 1% stable. On Thu, Aug 4, 2022 at 10:05 AM Alex Russell <slightly...@chromium.org> wrote: > 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/CALoDvsYjf2trGu1iBt0jJ8yQEbMOV3wOj-e1itMC4qibSj1MXA%40mail.gmail.com.
