Re: [w3ctag/design-reviews] Paint/presentation timestamps in performance APIs (Issue #1013)

mmocny left a comment (w3ctag/design-reviews#1013)

I agree that https://github.com/w3c/paint-timing/issues/62 doesn't have adequate detail about why we arrived at this specific solution.

For better historical context, I would read through:
- https://github.com/w3c/largest-contentful-paint/issues/104
  - As far back as 2022 this was the [proposed solution agreed amongst multiple implementers](https://github.com/w3c/largest-contentful-paint/issues/104#issuecomment-1271823151)
  - Was attempted as an interop project in 2023 but was too nascent
  - Was finally done as part of interop 2025 (and is now already part of baseline)
- Far more discussion, and links to Perf WG meeting minutes linked from https://github.com/w3c/largest-contentful-paint/issues/91

---

But let me also try to summarize the status and value:

- `paintTime` is technically not a user perceivable timepoint, and technically only marks an internal scheduling timestamp.
- It is not quite as valuable as `presentationTime`, which indeed does better to capture the effects of graphics workload, and is more accurately representative of user experience.
- However, `presentationTime` is not interoperably available across all browsers, nor is it strictly better in every way.
  - Chromium has been using this timestamp for various metrics (such as FCP, LCP, Event Timing, etc) for years.  Mozilla have signalled a willingness to implement it.  Safari has thus far not signalled a willingness to do so.
- `paintTime` also offers a unique value relative to `presentationTime`: it marks the final time point of each animation frame _on the main thread_.
  - Although there is typically a small amount of extra latency to present the frame (and sometimes a large amount of extra latency), it is useful to know the effect of the main thread in isolation for several reasons:
  - As a performance metric, having both paint and presentation times available you can more easily know if the latency was caused by e.g. javascript or style/layout vs e.g. css effects or decode/rasterization work
  - Beyond that, the paintTime is very useful to segment the overall timeline.  E.g. if you want to understand what the state of the DOM was, and which tasks affected a long paint, you need to segment by the main thread time only.  Presentation time is an asynchronous value and any main thread updates that overlap with this latency don't directly affect the latency.


There is probably a lot more to be said, or some more presentations to share-- but the real TL;DR is:

- It helped make performance timeline interoperable (successfully so!)
- It has proven useful to developers even in implementations that have exposed both values together.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1013#issuecomment-3792116303
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1013/3792116303@github.com>