This is a common programming pattern:
requestAnimationFrame(() => {
setTimeout(() => {
// At this point, it's very likely that layout is clean,
// because we *just* completed a rendering update.
// Queries of layout information are very unlikely to
// trigger a forced layout.
document.body.offsetTop;
});
});
Aligning timers will make this strategy for avoiding forced layout less
effective, because other non-timer tasks may run ahead of the setTimeout
and invalidate layout.
Also: the rAF(setTimeout()) construct is used extensively in chromium's
test corpus, to schedule work ASAP after a rendering update. Many of our
tests use a synchronous compositor: rendering updates happen without delay
whenever there are no other tasks ready to run. In other tests, we increase
the frequency of rendering updates from 60Hz to 200Hz, just because we know
there won't be any long-running tasks and we want the tests to run faster.
So... I see potential issues here.
On Wed, Aug 3, 2022 at 6:50 AM Etienne Pierre-doray <etien...@chromium.org>
wrote:
> 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
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsaQA8iqxdxNEh1PkBCzPFSsSSmZ72Jgmev-bdwenG6DrQ%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/CAHOQ7J-pruChSM-Wm-cAtWUg6YuzBHumB%3D5Zdo8zjUMqJCn%3Dcg%40mail.gmail.com.
