Can you comment as to what exactly would Chromium measure for presentationTime. It's mentioned as optional in the Gecko intent, and implementation defined here.
I'm wondering if it would expose GPU contention from other renderers that is otherwise not exposed? I realize this is coarse time but I'm trying to understand if there is any new timing information that presentationTime would provide, or is everything already discoverable by other means Thanks, Vlad On Wednesday, December 3, 2025 at 10:59:44 AM UTC-5 Yoav Weiss wrote: > LGTM1 > > On Wednesday, December 3, 2025 at 4:56:04 PM UTC+1 Michal Mocny wrote: > > Yes, on top of. startTime is defined in terms of renderTime which is now > defined in terms of paint/presentation times. > > So this just exposes the individual values that were already used for the > calculations. > > > Thank you! exposing those on top of the current attributes means that > there's no real compat risk here. Firefox being supportive significantly > reduces interop risk. > > > > On Wednesday, December 3, 2025 at 10:51:35 AM UTC-5 Yoav Weiss wrote: > > I should know this but do I understand correctly and this is adding > `paintTime` and `presentationTime` *on top* of existing attributes such as > `renderTime`/`startTime`/etc? > > On Thursday, November 27, 2025 at 11:49:01 AM UTC+1 Chromestatus wrote: > > *Contact emails* > [email protected], [email protected] > > > > *Explainer* > https://github.com/w3c/paint-timing/blob/main/presentation-timestamps.md > > *Specification* > https://w3c.github.io/paint-timing/#painttimingmixin > > *Summary* > Expose "paintTime" and "presentationTime" in element timing, LCP, long > animation frames, and paint timing. "paintTime" means the time when the > rendering phase ended and the browser started the paint phase. > "presentationTime" means the time when the "pixels reached the screen", > which is somewhat implementation-defined. This feature entry omits event > timing, which would be done separately. > > *Blink component* > Blink>PerformanceAPIs > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPerformanceAPIs%22> > > *Web Feature ID* > performancetiming <https://webstatus.dev/features/performancetiming> > > *Motivation* > So far the spec defined the paint time as the time after the "rendering > update", when the document hands over rendering to the UA. However, in > chromium the exposed paint time (in event timing, element timing, LCP and > paint-timing) was different - the approximated VSync time from the > compositor, which is important in terms of UX. This created confusion and > incompatibility This proposal defines both these timestamps, and exposes > them in an identical way in all the relevant entries. > > *Initial public proposal* > https://github.com/w3c/paint-timing/issues/62 > > *TAG review* > https://github.com/w3ctag/design-reviews/issues/1013 > > *TAG review status* > Pending > > *Risks* > > > *Interoperability and Compatibility* > *No information provided* > > *Gecko*: Positive (https://github.com/mozilla/standards-positions/ > issues/1110) Firefox folks took part of the WebPerfWG meeting where this > was discussed/resolved. > > *WebKit*: In development (https://github.com/WebKit/standards- > positions/issues/426) > > *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? > *No information provided* > > > *Debuggability* > *No information provided* > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, 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 > > > *Flag name on about://flags* > *No information provided* > > *Finch feature name* > PaintTimingMixin > > *Rollout plan* > Will ship enabled for all users > > *Requires code in //chrome?* > False > > *Tracking bug* > https://issues.chromium.org/issues/378827535 > > *Estimated milestones* > Shipping on desktop144 Shipping on Android144 Shipping on WebView144 > > *Anticipated spec changes* > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > None. This is already part of interop 2025. Note that the TAG review was > delayed because some things in the explainer were missing initially. > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/5162859838046208?gate=5137700305502208 > > *Links to previous Intent discussions* > Intent to Prototype: https://groups.google.com/a/ > chromium.org/d/msgid/blink-dev/67347e70.2b0a0220.3644d. > 01e9.GAE%40google.com > > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com>. > > -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3be2bb78-078f-46c8-9e24-df9bf80959a7n%40chromium.org.
