-
Notifications
You must be signed in to change notification settings - Fork 25.1k
Ensure full layout occurs when a system scale change occurs #45047
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2140,7 +2140,8 @@ bool calculateLayoutInternal( | |
|
|
||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These files will ultimately get synced everywhere, but we usually prefer changes against Yoga to be made against the Yoga repo (which will run some additional validation in OSS as well). Yoga is also pretty heavily unit tested, so we would want to add a test alongside this. Unit tests are run automatically against the Yoga repo, but there is also a |
||
| const bool needToVisitNode = | ||
| (node->isDirty() && layout->generationCount != generationCount) || | ||
| layout->lastOwnerDirection != ownerDirection; | ||
| layout->lastOwnerDirection != ownerDirection || | ||
| layout->lastScale != node->getConfig()->getPointScaleFactor(); | ||
|
Comment on lines
+2143
to
+2144
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There is logic today, to try to account for pointScaleFactor when we are comparing layout constraints for cache reuse (compared to logic that has gotten chained here for dirtying all results): https://github.com/facebook/yoga/blob/baf670e261892ad4e72c5c02b6ff671537b661a7/yoga/algorithm/Cache.cpp#L64 I wouldn't be surprised if there are issues with the current interaction of layout rounding and caching, but we should probably only do this invalidation in one place (and make sure we have tests that it works, if we don't right now). |
||
|
|
||
| if (needToVisitNode) { | ||
| // Invalidate the cached results. | ||
|
|
@@ -2255,6 +2256,7 @@ bool calculateLayoutInternal( | |
| reason); | ||
|
|
||
| layout->lastOwnerDirection = ownerDirection; | ||
| layout->lastScale = node->getConfig()->getPointScaleFactor(); | ||
|
|
||
| if (cachedResults == nullptr) { | ||
| layoutMarkerData.maxMeasureCache = std::max( | ||
|
|
||
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.
We have a down-propagation/inheritance step, during commit, once we have the full shadow-tree constructed, where we propagate
pointScaleFactorto every Yoga node.react-native/packages/react-native/ReactCommon/react/renderer/components/view/YogaLayoutableShadowNode.cpp
Line 462 in d8739e1
YGNodeSetConfigwill do a comparison of previous and current config to dirty node (though changing something on the actual config after-the-fact does not, which is an API bug). So this code has a defect where it is not dirtying underlying Yoga node, if pointScaleFactor changes.We probably want to fixup the invalidation when setting pointScaleFactor (either there in RN, or in Yoga), instead of just invalidating the root node.
An aside, I know the code already does this, but this method of dirtying that Fabric uses is a smell (and Yoga's public API only allows dirtying nodes with measure functions which can be impacted by external changes). Yoga tries to manage dirtying in all other cases, when APIs are called which mutate style or config.
RootShadowNode::layoutIfNeededshould normally be able to run, even if the node is not dirty, and work only happens if the passed in constraints have changed.