-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[motion-path] Check if we are mid layout when setting containing block rect for ray #16633
Conversation
EWS run on previous version of this PR (hash dcfc057) |
dcfc057
to
06e6453
Compare
EWS run on previous version of this PR (hash 06e6453)
|
06e6453
to
a6edd43
Compare
EWS run on previous version of this PR (hash a6edd43)
|
a6edd43
to
5022957
Compare
EWS run on previous version of this PR (hash 5022957)
|
5022957
to
3b896cc
Compare
EWS run on previous version of this PR (hash 3b896cc)
|
3b896cc
to
d903dfd
Compare
EWS run on previous version of this PR (hash d903dfd)
|
auto& rayPathOperation = downcast<RayPathOperation>(*pathOperation); | ||
auto pathReferenceBoxRect = snapRectToDevicePixelsIfNeeded(parentBlock->transformReferenceBoxRect(parentBlock->style()), *this); | ||
if (auto* containingBlockFlow = dynamicDowncast<RenderBlockFlow>(parentBlock)) { | ||
if (parentBlock->needsLayout() && !containingBlockFlow->wasMarkedNeedingTransformUpdate(this)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bit gross that this sets some state on the containingBlockFlow
. Why not just change the code to always update motion path things after the containing block has finished layout?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed to set this state in RenderLayer::updateTransform and moved the rest to MotionPathHelper.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if RenderLayer::updateTransform()
is the right place to set this state. We can either set it here or we have to set in every RenderObject
subclass where we call updateLayerTransform()
in the individual layout()
functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved the marking of needing a transform update to RenderLayerModelObject::updateLayerTransform
.
d903dfd
to
df4af25
Compare
EWS run on previous version of this PR (hash df4af25) |
a423034
to
0f378d6
Compare
EWS run on previous version of this PR (hash 0f378d6)
|
EWS run on previous version of this PR (hash a423034)
|
0f378d6
to
a716265
Compare
EWS run on previous version of this PR (hash a716265) |
a716265
to
1cb7aaa
Compare
EWS run on previous version of this PR (hash 1cb7aaa) |
@@ -3548,4 +3548,14 @@ LayoutUnit RenderBlock::layoutOverflowLogicalBottom(const RenderBlock& renderer) | |||
return std::max(renderer.clientLogicalBottom(), maxChildLogicalBottom + renderer.paddingAfter()); | |||
} | |||
|
|||
void RenderBlock::updateDescendantTransformsAfterLayout() | |||
{ | |||
auto descendants = view().frameView().layoutContext().descendantsNeedingTransformUpdate(this); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could still be takeBoxesNeedingTransformUpdateAfterContainerLayout()
which would extract them from the hash map, and remove the need for finishedUpdatingDescendants()
.
6db36a2
to
af3d612
Compare
EWS run on previous version of this PR (hash af3d612) |
EWS run on previous version of this PR (hash 6db36a2)
|
af3d612
to
e32fb19
Compare
EWS run on previous version of this PR (hash e32fb19) |
LayoutTests/imported/w3c/web-platform-tests/css/motion/offset-path-ray-022.html
Outdated
Show resolved
Hide resolved
e32fb19
to
653d25c
Compare
EWS run on current version of this PR (hash 653d25c) |
…k rect for ray https://bugs.webkit.org/show_bug.cgi?id=260110 rdar://113780201 Reviewed by Simon Fraser. On the first RenderLayer::updateTransform call the parent is mid layout, so it is inorrect to query it about its rect size. If we have a motion path transform, set that this RenderObject needs a transform update on the parent through the FrameView's layout context, and have the parent call updateTransform after it has completed layout. * LayoutTests/TestExpectations: * LayoutTests/imported/w3c/web-platform-tests/css/motion/offset-path-ray-019-expected.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/motion/offset-path-ray-019.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/motion/offset-path-ray-020-expected.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/motion/offset-path-ray-020.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/motion/offset-path-ray-021-expected.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/motion/offset-path-ray-021.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/motion/offset-path-ray-022-expected.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/motion/offset-path-ray-022.html: Added. Canonical link: https://commits.webkit.org/267479@main
653d25c
to
acfa97d
Compare
Committed 267479@main (acfa97d): https://commits.webkit.org/267479@main Reviewed commits have been landed. Closing PR #16633 and removing active labels. |
acfa97d
653d25c
🧪 wpe-wk2🧪 gtk-wk2🧪 mac-AS-debug-wk2