Consolidate `paintTime` and `presentationTime` in performance APIs

[noamr]

WebKittens

@achristensen11 @smfr

Title of the proposal

Paint timing

URL to the spec

https://w3c.github.io/paint-timing

URL to the spec's repository

https://github.com/w3c/paint-timing

Issue Tracker URL

No response

Explainer URL

https://github.com/w3c/paint-timing/blob/main/presentation-timestamps.md

TAG Design Review URL

https://github.com/w3ctag/design-reviews/issues/1013

Mozilla standards-positions issue URL

https://github.com/mozilla/standards-positions/issues/1110

WebKit Bugzilla URL

No response

Radar URL

No response

Description

This has been discussed at the WebPerfWG. See w3c/paint-timing#62

[smfr]

I have a memory that Chrome uses the presentationTime as the values passed to requestAnimationFrame, rather than the now timestamp that the spec says. If so, it would be good to resolve this behavior difference at the same time, as they seem connected.

[noamr]

I have a memory that Chrome uses the presentationTime as the values passed to requestAnimationFrame, rather than the now timestamp that the spec says. If so, it would be good to resolve this behavior difference at the same time, as they seem connected.

Also Gecko, and the spec was corrected to reflect that a while ago. See https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model:last-render-opportunity-time-4