Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 7de5d103812b0f8da9ff696e9058bc13011a6da3
https://github.com/WebKit/WebKit/commit/7de5d103812b0f8da9ff696e9058bc13011a6da3
Author: Wenson Hsieh <[email protected]>
Date: 2025-04-29 (Tue, 29 Apr 2025)
Changed paths:
M Source/WebCore/SaferCPPExpectations/UncountedLocalVarsCheckerExpectations
M Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp
M Source/WebCore/page/scrolling/ScrollingCoordinator.h
M Source/WebCore/page/scrolling/ScrollingStateNode.h
M Source/WebCore/page/scrolling/ScrollingStateStickyNode.cpp
M Source/WebCore/page/scrolling/ScrollingStateStickyNode.h
M Source/WebCore/page/scrolling/ScrollingTreeStickyNode.cpp
M Source/WebCore/page/scrolling/ScrollingTreeStickyNode.h
M Source/WebCore/page/scrolling/cocoa/ScrollingTreeStickyNodeCocoa.h
M Source/WebCore/page/scrolling/cocoa/ScrollingTreeStickyNodeCocoa.mm
M Source/WebCore/rendering/RenderLayerBacking.cpp
M Source/WebCore/rendering/RenderLayerBacking.h
M Source/WebCore/rendering/RenderLayerCompositor.cpp
M
Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.serialization.in
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm
M
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.mm
Log Message:
-----------
[Viewport Clipping] [Part 3/4] Plumb the viewport anchor layer through the
scrolling tree
https://bugs.webkit.org/show_bug.cgi?id=292124
rdar://150150239
Reviewed by Abrar Rahman Protyasha.
Continue working towards clipping fixed and sticky elements to the viewport. In
this patch, we add
plumbing for the viewport anchor layer through scrolling tree and scrolling
state nodes. At the
moment, this viewport anchor layer is redundant with the scrolling tree/state
node's layer; however,
in the next and final patch, we'll add a new clipping layer which will replace
the anchor layer as
the scrolling node's primary layer, in the case where the fixed or sticky
element is clipped to the
viewport.
See below for more details; no change in behavior yet.
* Source/WebCore/SaferCPPExpectations/UncountedLocalVarsCheckerExpectations:
* Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp:
(WebCore::AsyncScrollingCoordinator::setNodeLayers):
Add `viewportAnchorLayer` to `NodeLayers`.
* Source/WebCore/page/scrolling/ScrollingCoordinator.h:
* Source/WebCore/page/scrolling/ScrollingStateNode.h:
Add a changed property flag corresponding to the viewport anchor layer.
* Source/WebCore/page/scrolling/ScrollingStateStickyNode.cpp:
(WebCore::ScrollingStateStickyNode::ScrollingStateStickyNode):
(WebCore::ScrollingStateStickyNode::applicableProperties const):
(WebCore::ScrollingStateStickyNode::setViewportAnchorLayer):
(WebCore::ScrollingStateStickyNode::computeAnchorLayerPosition const):
Split `computeLayerPosition` into two methods: one to compute the position of
the anchor layer, and
another to compute the position of the clipping layer (to be introduced in the
next patch). Note
that both of these positions are relative to the sticky node's parent layer.
(WebCore::ScrollingStateStickyNode::computeClippingLayerPosition const):
Add a new method to return the position of the (soon-to-exist) clipping layer.
(WebCore::ScrollingStateStickyNode::reconcileLayerPositionForViewportRect):
Teach this to update both the viewport anchor layer as well as the viewport
clipping layer. In the
case where the clipping layer doesn't exist, we fall back to existing behavior
(i.e. blitting the
anchor layer to the anchor layer position); however, if the clipping layer
exists, we'll instead
blit the clipping layer and then counter-blit the anchor layer as needed.
(WebCore::ScrollingStateStickyNode::hasViewportClippingLayer const):
Add a helper method to return whether or not the scrolling node has a viewport
clipping layer (i.e.
whether the primary scrolling node layer is different from the viewport anchor
layer).
(WebCore::ScrollingStateStickyNode::scrollDeltaSinceLastCommit const):
Use the clipping layer here when computing scroll delta, if it exists.
(WebCore::ScrollingStateStickyNode::computeLayerPosition const): Deleted.
* Source/WebCore/page/scrolling/ScrollingStateStickyNode.h:
* Source/WebCore/page/scrolling/ScrollingTreeStickyNode.cpp:
(WebCore::ScrollingTreeStickyNode::computeClippingLayerPosition const):
Add a new method to return the position of the (soon-to-exist) clipping layer,
by calling into
`ScrollingStateViewportConstrainedNode::computeLayerPosition`.
(WebCore::ScrollingTreeStickyNode::scrollDeltaSinceLastCommit const):
Match `ScrollingStateStickyNode::scrollDeltaSinceLastCommit`.
* Source/WebCore/page/scrolling/ScrollingTreeStickyNode.h:
(WebCore::ScrollingTreeStickyNode::hasViewportClippingLayer const):
* Source/WebCore/page/scrolling/cocoa/ScrollingTreeStickyNodeCocoa.h:
* Source/WebCore/page/scrolling/cocoa/ScrollingTreeStickyNodeCocoa.mm:
(WebCore::ScrollingTreeStickyNodeCocoa::commitStateBeforeChildren):
Set `m_viewportAnchorLayer` based on the sticky state node's viewport anchor
layer representation.
(WebCore::ScrollingTreeStickyNodeCocoa::applyLayerPositions):
Match the changes in `reconcileLayerPositionForViewportRect` above, by only
blitting the anchor
layer to its updated position in the case where the clipping layer doesn't
exist; otherwise, blit
the containing clipping layer to match the viewport rect while scrolling, and
simultaneously
counter-blit the anchor layer underneath.
(WebCore::ScrollingTreeStickyNodeCocoa::hasViewportClippingLayer const):
Add a helper method to return whether or not the scrolling node has a viewport
clipping layer (i.e.
whether the primary scrolling node layer is different from the viewport anchor
layer).
* Source/WebCore/rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateDebugIndicators):
Drive-by fix: fix a typo in this comment.
(WebCore::RenderLayerBacking::childForSuperlayersExcludingViewTransitions
const):
Use the more generic `viewportClippingOrAnchorLayer()` here, instead of
returning the viewport
anchor layer. This method just returns `m_viewportAnchorLayer` right now, but
once the clipping
layer is introduced, it will return the clipping layer instead (which will
contain the anchor
layer).
* Source/WebCore/rendering/RenderLayerBacking.h:
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::didChangePlatformLayerForLayer):
Set both the new `viewportAnchorLayer` alongside `layer` on `NodeLayers`; these
are always identical
for now, but in the next patch will change such that `layer` points to the
outer layer that needs to
be repositioned when the scrolling node changes, while `viewportAnchorLayer`
will continue to point
to just the anchor layer.
(WebCore::RenderLayerCompositor::computeFixedViewportConstraints const):
(WebCore::RenderLayerCompositor::computeStickyViewportConstraints const):
Adopt `viewportClippingOrAnchorLayer` here, instead of just using
`viewportAnchorLayer` to compute
rects for the viewport constraints.
(WebCore::RenderLayerCompositor::updateScrollingNodeForViewportConstrainedRole):
*
Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.serialization.in:
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
*
Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm:
(WebKit::RemoteScrollingCoordinatorProxyIOS::connectStateNodeLayers):
*
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.mm:
(WebKit::RemoteScrollingCoordinatorProxyMac::connectStateNodeLayers):
Add Cocoa-specific logic to update scrolling state tree nodes with the viewport
anchor layer, by
mapping layer ID to platform `CALayer`.
Canonical link: https://commits.webkit.org/294311@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
