Repository navigation
Add Support for the ContainerTiming PaintMetric - #46966
Conversation
4f18c08 to
bd2d948
Compare
|
@jasonwilliams I've been ignoring this because it's marked as a draft. Are you waiting for someone to review it? |
Thanks for reaching out @jdm, no not yet, it’s still a WIP. Ill mark it as review and ping you when I need reviews. |
0282ab5 to
83e2dc0
Compare
|
Yeah, Nice. Please put a separate PR to enable WPT for Edit: + With WPT (Failing) Expectations |
88ae8e7 to
f93db82
Compare
Done: #48290 |
|
Test results for linux-wpt from try job (#37294387426): Flaky unexpected result (21)
Stable unexpected results that are known to be intermittent (11)
|
|
✨ Try run (#37294387426) succeeded. |
This enables testing for the experimental [container timing](https://wpt.fyi/results/container-timing/tentative?label=experimental&label=master&aligned) within WPT Part of servo#46966 Signed-off-by: jasonwilliams <jase.williams@gmail.com>
90d9f7e to
bcfaa24
Compare
bcfaa24 to
0a2c3f6
Compare
Initial start by setting experimental runtime flags and support in Node and Base fragments. This is to reduce the cost of traversal to discover if container timing is needed Signed-off-by: jasonwilliams <jase.williams@gmail.com>
Signed-off-by: jasonwilliams <jase.williams@gmail.com>
Signed-off-by: jasonwilliams <jase.williams@gmail.com>
- Update paint_regions within a pending container, then merge into the permenent container record when the display list has finished building - Fix up some WPT's by checking the node itself for the container root before starting at the parent Signed-off-by: jasonwilliams <jase.williams@gmail.com>
`container_id` was always `root_element.id()`. Key by the root element's `OpaqueNode` instead. Signed-off-by: jasonwilliams <jase.williams@gmail.com>
Signed-off-by: jasonwilliams <jase.williams@gmail.com>
Instead of walking up the DOM trying to find container roots, use the traversalState to pass roots down instead. LCP has been doing this with text decorations etc. We have a ContainerTimingRoots linked list which starts at the nearest root then follows on until None. This allows us to implement containertimingignore and pass more tests. This should also have much improved performance, because there is no "lookup" now which iterates every single node up the tree, we know ahead of time where the roots are. The identifier is now read later on in script a we have access to the root element here anyway, we check again if the attribute is there, and if not we skip. Signed-off-by: jasonwilliams <jase.williams@gmail.com>
0a2c3f6 to
a2f50e5
Compare
|
@servo-highfive monthly update |
|
Someone thinks this change could be added to the monthly blog post! To help with this, we need someone to answer the following questions: 😄
If this change is part of a broader feature/project please make sure the PR description contains a Please add Thanks for helping us prepare the monthly blog post! ❤️ |
This enables testing for the experimental [container timing](https://wpt.fyi/results/container-timing/tentative?label=experimental&label=master&aligned) within WPT Part of servo#46966 Signed-off-by: jasonwilliams <jase.williams@gmail.com>
Hi, I'm a spec champion for the Container Timing feature and I wanted to add it to Servo (behind a flag). The Container Timing API enables monitoring when annotated sections of the DOM are displayed on screen and have finished their initial paint. I am one of the spec authors, and i've been helping this land in both [Chromium](https://developer.chrome.com/blog/container-timing-origin-trial) and [Firefox](https://phabricator.services.mozilla.com/D279373) This PR implements the [Container Timing API](https://github.com/WICG/container-timing), following the same layout > paint > constellation pipeline already used for LCP. Steps for calculating Container Timing: 1. When an element has the `containertiming` attribute, a [flag is propagated down through its descendants](https://github.com/jasonwilliams/servo/blob/403908fa99f47da3e18faaca88d2abdb01498cf7/components/script/dom/node/node.rs#L378-L387) (set on the Node/fragment) so layout can cheaply tell "is this inside a container-timing root" without walking back up the tree on every fragment. 2. While building the display list, each painted text/image fragment that belongs to a container-timing root [reports its viewport-clipped size and rect to a PaintTimingHandler](https://github.com/jasonwilliams/servo/blob/403908fa99f47da3e18faaca88d2abdb01498cf7/components/layout/display_list/mod.rs#L706-L718), similar to how LCP candidates are collected. 3. PaintTimingHandler keeps one running record per container root (keyed by a stable node ID, since the containertiming value itself is optional and not unique), accumulating size/rect across paints, and tracks which containers were actually touched since the last hand-off. 4. Layout [hands the finished per-container records to script](https://github.com/jasonwilliams/servo/blob/403908fa99f47da3e18faaca88d2abdb01498cf7/components/layout/layout_impl.rs#L1561-L1567) as part of the reflow result 5. once webrender confirms that epoch composited, [it sends PaintMetricEvent::ContainerTiming(paint_time, ids)](https://github.com/jasonwilliams/servo/blob/403908fa99f47da3e18faaca88d2abdb01498cf7/components/paint/painter.rs#L585-L589) to script, which stamps the already-stored records with the real paint/first-render time and queues the finished PerformanceContainerTiming entries. Testing: - There are plenty of [Web Platform Tests](https://wpt.fyi/results/container-timing/tentative?label=master&label=experimental&aligned&q=container%20timing) for Container Timing. I have been testing the build against these as i have been going along, 19/29 tests pass. - There are tests for some components, such as paintedRegion Follow ups & investigation: - `lastPaintedElement` selection picks by traversal order, not largest area - [Tidy Up] The `effective_visual_size` check was [originally written for LCP](servo#43378), but is useful for Container Timing as well, we should make this API generic --------- Signed-off-by: jasonwilliams <jase.williams@gmail.com>
|
@servo-highfive monthly update answer
|
Hi, I'm a spec champion for the Container Timing feature and I wanted to add it to Servo (behind a flag).
The Container Timing API enables monitoring when annotated sections of the DOM are displayed on screen and have finished their initial paint. I am one of the spec authors, and i've been helping this land in both Chromium and Firefox
This PR implements the Container Timing API, following the same layout > paint > constellation pipeline already used for LCP.
Steps for calculating Container Timing:
containertimingattribute, a flag is propagated down through its descendants (set on the Node/fragment) so layout can cheaply tell "is this inside a container-timing root" without walking back up the tree on every fragment.Testing:
Follow ups & investigation:
lastPaintedElementselection picks by traversal order, not largest areaeffective_visual_sizecheck was originally written for LCP, but is useful for Container Timing as well, we should make this API generic