Sounds good. Thanks for the explanation LGTM3
On Wednesday, December 3, 2025 at 11:35:57 AM UTC-5 [email protected] wrote: > Background: presentation time itself has been exposed to many > paint-related apis (like LCP), for years already. This new API doesn't > change in any way what is exposed to developers in Chromium-- but today > these values are somewhat indirectly and inconsistently reported as > startTime, renderTime, or startTime+duration, depending on the api. > > This new API was added to help with interop (to make it clearer what > values are actually being reported), and to help with developer ergonomics > (i.e. make the reporting consistent across entry types). > > (Not dismissing the question about reporting risks, but clarifying that > this was already evaluated in the past and this feature doesn't change > status quo at all.) > > Also, I believe Gecko is working towards exposing presentationTime as well. > > On Wednesday, December 3, 2025 at 11:12:19 AM UTC-5 [email protected] > wrote: > >> 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/d8ba43e0-7532-4785-bc6b-fb94810bc534n%40chromium.org.
