[webkit-changes] [WebKit/WebKit] fdd47d: [margin-trim] Change RenderLayoutState's m_blockSt...
Sammy Gill
noreply at github.com
Mon Dec 16 09:05:44 PST 2024
Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: fdd47d1fbc4d9dc87074fe3d75bafc240e194b0b
https://github.com/WebKit/WebKit/commit/fdd47d1fbc4d9dc87074fe3d75bafc240e194b0b
Author: Sammy Gill <sammy.gill at apple.com>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M Source/WebCore/rendering/RenderBlockFlow.cpp
M Source/WebCore/rendering/RenderLayoutState.cpp
M Source/WebCore/rendering/RenderLayoutState.h
Log Message:
-----------
[margin-trim] Change RenderLayoutState's m_blockStartTrimming to bool.
https://bugs.webkit.org/show_bug.cgi?id=284566
rdar://problem/141370964
Reviewed by Alan Baradlay.
In preparation to fix a margin-trim invalidation bug, let's change the
m_blockStartTrimming field in RenderLayoutState from a Vector<bool>
to being simply a bool. This makes it easier to maintain and can be used
to perform the same task.
This field is supposed to be a stack which keeps track of whether or not
we should be attempting to trim the block-start margins for a
particular subtree. A block container checks to see what the value is at
the top of the stack in order to determine if it should trim the
margins of its children. The container may set this value to false to
indicate that it should no longer trim its children's margins (e.g.
because maybe the child's and subsequent children's margins will no
longer be at the block-start side of the block container). This would
also mean that any subtree from this point should no longer try to trim
margins.
If we change this field to a bool we can achieve the same effect by:
1.) Having the block container keep track of the old value of
blockStartTrimming (that was propagated from its containing block) and
compute a new value that it will use for its children.
2.) Restore the old value when it’s done laying out its children so that
its containing block can continue to use the value it computed before.
This should be essentially the same logic that we were performing
before but are just holding onto the information slightly differently.
* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::layoutBlockChildren):
Previously, we were pushing a newly computed value for blockStartTrimming
that would be used by the block container. We will continue to
compute this same value but also keep track of the old one. The only
difference is that there was previously a scenario in which we did not
modify RenderLayoutState at all if there was no trimming being done, but
let's just coalesce this into the logic of further propagating the
value we got from our containing block to make things simpler.
At the end of the method, instead of popping from the stack, just restore
the old value via a ScopeExit.
(WebCore::RenderBlockFlow::layoutBlockChild):
Here we would set blockStartTrimming to false if we could no longer
trim the margins for the subtree. Do this by directly updating the
value on RenderLayoutState.
(WebCore::RenderBlockFlow::collapseMarginsWithChildInfo):
We would only trim the margins if the value at the top of the stack
(i.e. the value computed for this block container) was true. We can
continue to do this by directly checking the value on RenderLayoutState.
* Source/WebCore/rendering/RenderLayoutState.cpp:
(WebCore::RenderLayoutState::RenderLayoutState):
* Source/WebCore/rendering/RenderLayoutState.h:
(WebCore::RenderLayoutState::RenderLayoutState):
(WebCore::RenderLayoutState::setBlockStartTrimming):
(WebCore::RenderLayoutState::blockStartTrimming const):
(WebCore::RenderLayoutState::pushBlockStartTrimming): Deleted.
(WebCore::RenderLayoutState::popBlockStartTrimming): Deleted.
Canonical link: https://commits.webkit.org/287885@main
To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications
More information about the webkit-changes
mailing list