Note: shipping PaintTimingMixin also gives PerformancePaintTiming its own toJSON method. This is a side effect of having additional properties in PerformancePaintTiming, which, before this change, shared the toJSON implementation with its superclass (PerformancePaintTiming).
On Wed, Dec 3, 2025 at 5:58 PM Vladimir Levin <[email protected]> wrote: > > 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 >>>> >>>> Web Feature ID >>>> 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? >>>> 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. -- 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/CAJn%3DMYZj0G6Vf8stEPGFc0ZaXNzWjND6i9%2BMkYup%2B_qF7f3RoQ%40mail.gmail.com.
