Slimming paint v2 does not currently understand position: sticky. This task involves:
1) Adding position:sticky information to the blink property tree builder.
2) Plumbing this data to cc's property trees.
3) Ensuring this works in the composited and non-composited codepaths.
Cc: chrishtr@google.com pdr@chromium.org Labels: -Pri-2 Pri-1 Owner: trchen@chromium.org Status: Started (was: Available) Summary: [Blink/BGPT] Implement sticky position in Blink transform tree (was: Implement sticky position in slimming paint v2)
We will need this earlier to support composited sticky position layer in BGPT.
The plan of record, as discussed today:
1. Compute the Blink equivalent of cc::StickyPositionNodeData in paint_property_tree_builder.cc.
2. Store it on the paint offset transform node for the composited layer of
the object with sticky constraints which ends up composited.
3. Copy the blink version to the cc version in PAC.
I found some sticky logic in Document::EnsurePaintLocationDataValidForNode. I think we may need to run the lifecycle past prepaint in more cases to ensure sticky is up-to-date.
I think we will be fine. The family of LayoutObject::MapToVisualRectInAncestorSpace() doesn't use property tree anyway.
My implementation strategy will leave StickyPositionScrollingConstraints computation to CompositingInputsUpdate, so the family of MapToVisualRectInAncestorSpace() can still refer to it as long as it is past CompositingInputsClean.
The other family that are based on GeometryMapper will need PrePaintClean, but that is already the case whether sticky is involved or not.
Comment 1 by trchen@chromium.org
, Aug 21Labels: -Pri-2 Pri-1
Owner: trchen@chromium.org
Status: Started (was: Available)
Summary: [Blink/BGPT] Implement sticky position in Blink transform tree (was: Implement sticky position in slimming paint v2)