-
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
[ASDisplayNode layout] Fix an issue that sometimes causes a node's pending layout to not be applied #792
[ASDisplayNode layout] Fix an issue that sometimes causes a node's pending layout to not be applied #792
Conversation
nguyenhuy
commented
Feb 6, 2018
- Since the implementation of layout version (Use a sentinel NSUInteger for node layout data #trivial #428), if a node's pending and calculated layouts have the same current version as well as the same constrained size, the 2 layouts are considered equal and can be used interchangeably. A layout version check between the 2 layouts was added in [ASDisplayNode+Layout] Ensure a pending layout is applied once #695. This PR adds a missing constrained size check.
- If the pending layout has the same version but a different constrained size compare to the calculated layout's, we can assume that the pending layout is newer and should be preferred over the calculated one. That is because layout operations always register their new layout as pending, which then (immediately or eventually) get applied to the node as calculated layout.
…ut to not be applied - Since the implementation of layout version (TextureGroup#428), if a node's pending and calculated layouts have the same current version as well as the same constrained size, the 2 layouts are considered equal and can be used interchangeably. A layout version check between the 2 layouts was added in TextureGroup#695. This PR adds a missing constrained size check. - If the pending layout has the same version but a different constrained size compare to the calculated layout's, we can assume that the pending layout is newer and should be preferred over the calculated one. That is because layout operations always register their new layout as pending, which then (immediately or eventually) get applied to the node as calculated layout.
980c94b
to
d2dc377
Compare
d2dc377
to
9958f86
Compare
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.
I like this change, but it may discard valid layouts. If the versions are equal, and they're both equal to the current version (_layoutVersion
) then we can safely use whichever layout matches the constrained size we're interested in.
So we can look at what constrained size we will use for this pass (down below at line 367):
ASSizeRange constrainedSize = [self _locked_constrainedSizeForLayoutPass];
And then if either layout's version and constrained size are valid (the version matches the node's _layoutVersion
and the constrained size matches this method's constrainedSize
) then we can skip the measure and use that layout.
Thoughts?
@Adlai-Holler You're right that we can use whichever layout fits the constrained size/bounds. However, currently Another concern is that, such behaviour will break the current implications of |
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.
I'm down with that!
Awesome. Thank you! |
…nding layout to not be applied (TextureGroup#792) * [ASDisplayNode layout] Fix an issue that causes a node's pending layout to not be applied - Since the implementation of layout version (TextureGroup#428), if a node's pending and calculated layouts have the same current version as well as the same constrained size, the 2 layouts are considered equal and can be used interchangeably. A layout version check between the 2 layouts was added in TextureGroup#695. This PR adds a missing constrained size check. - If the pending layout has the same version but a different constrained size compare to the calculated layout's, we can assume that the pending layout is newer and should be preferred over the calculated one. That is because layout operations always register their new layout as pending, which then (immediately or eventually) get applied to the node as calculated layout.