Sounds good, thanks! I don't think we need additional reviews for such a
minor addition.
On 12/5/25 10:33 a.m., Noam Rosenthal wrote:
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/1fa3f959-a8f3-455c-84df-945121328451%40chromium.org.
