Align Timers (including DOM timers) at 125 Hz

[eti-p-doray]

Request for position on an emerging web specification

Information about the spec

• Spec Title: Align Timers (including DOM timers) at 125 Hz
• Spec URL: https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
• Issue Tracker (if not the repository's issue tracker): https://crbug.com/1153139
• ChromeStatus entry: https://chromestatus.com/feature/5680188671655936
• Demo page (Chromium has experimental implementation): https://github.com/eti-p-doray/align-wakeups/blob/main/HOWTO.md

Anything else we need to know

Note that this is not a new spec. This Chrome feature changes the behavior of an existing web API in a way that is spec-compliant. The feature runs 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.

[gsnedders]

@eti-p-doray why 125Hz? nothing seems to specify why that; I can guess that some of this is wanting millisecond-aligned, but why 8ms and not 16ms, for example? if the belief is that almost every case that needs higher precision can use something better, why not be even more aggressive here?

(that said, from a standards position POV: I believe we're fine with this part of the HTML standard, and this change in behaviour from Chrome isn't a change from a standards point-of-view, even if it might be worth aligning on!)

cc @cdumez @smfr

https://github.com/WebKit/WebKit/blob/ecde243930f2bd6202905b67322b95a38e6b9119/Source/WebCore/page/DOMTimer.h#L48 is our current implementation here; I think we apply a minimum of 4ms to all timers, and then the different types of alignment are closer to what's described here (0ms by default, 30ms in low-power mode, 30ms in cross-origin frames the user hasn't interacted with, 1s for hidden pages). Hopefully @cdumez can correct me if I'm wrong!

[eti-p-doray]

For context, it was suggested I ask about WebKit's position on this in this blink-dev discussion: https://groups.google.com/a/chromium.org/g/blink-dev/c/POCUbyCqnrc/m/QcpmsLGwDQAJ?utm_medium=email&utm_source=footer

Re. why 8ms; this is somewhat arbitrary (akin to the 4ms min clamping present in the spec). One reason for 8ms is alignment with frame rate (that's true for 16ms as well, although Mac now has ProMotion with 120 Hz display? crbug.com/1261194). From locally experiments, we determined that 8ms gives us a big portion of the gains that 16ms brings, and is presumably less risky of breaking things. While I've been pushing for 8ms, there are already proposals to make it 16ms in some situations (e.g. in low-power mode).

Thanks for the context on WebKit, that's super useful.

[smfr]

It's really weird to align timers on some frequency that's not a multiple of the "update the rendering" frequency, typically 60Hz. Doing this will cause more CPU wakeups and be a large power regression; WebKit will not implement this.

if you want to align timers, use some multiple of the "update the rendering" frequency, and allow it to change with display refresh frequency.

[smfr]

Note that WebKit already has some DOM timer alignment logic (see Page::updateDOMTimerAlignmentInterval()), which depends on low power mode, page visibility and user interaction. It's also possible that there's some alignment logic at the platform level which is designed to reduce CPU wakeups.

[litherum]

Why does this need to be standardized? Different browsers have had different timer quantization since the beginning of time.

In particular, this strikes me as forcing a single position on the "fidelity vs security/privacy" tradeoff, which is a tradeoff that different browsers have historically picked different positions on. If a browser wants to quantize more to protect privacy/security better, they should be allowed to do that.

[geoffreygaren]

An impact of Simon's comment about "platform level" is that, even if there were a web specification, and even if a browser faithfully tried to implement it, the web programmer would still not get the specified behavior on most hardware and operating systems most of the time. Seems like a not-good way to write a spec.

[eti-p-doray]

Why does this need to be standardized? Different browsers have had different timer quantization since the beginning of time.

Agreed, I have no intention to standardize any form of throttling (sorry if that wasn't clear), and I have no intention to change the spec. This technically already fits within the spec as-is; "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. The question is rather about whether intentionally throttling/aligning DOM timers in foreground page is reasonable (blink also does 1s throttling for background pages), and whether WebKit does it. It seems WebKit already does it to some extent, I suppose this partly answers the question.

It's also possible that there's some alignment logic at the platform level which is designed to reduce CPU wake-ups.

Windows has different timer resolution, Mac has default task leeway (that's a percentage of sleep time). Considering these, I don't think we can expect setTimeout() to be millisecond accurate in general.

It's really weird to align timers on some frequency that's not a multiple of the "update the rendering" frequency, typically 60Hz.

Fair enough. In practise, this is implemented close to the platform and timers are pumped on every wake up, so vsync may end up driving wake ups. In the absence of any kind of precise timer, DOM timers will end up aligning on a 8ms tick.

[smfr]

vsync may end up driving wake ups

This is the common case, I think. If any code runs that triggers a rendering update, then that rendering update will happen based on a vsync-aligned trigger. It makes sense to me that you try to group timer work with rendering update work, so they all happen in one batch of CPU activity. If you want additional timer alignment, do it at 1/2 or 1/4 frame intervals.

[othermaciej]

Agreed, I have no intention to standardize any form of throttling (sorry if that wasn't clear), and I have no intention to change the spec. This technically already fits within the spec as-is;

In that case, this seems like it's not a request for a standards position, since there's no standard and none is proposed.