-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Avoid calling performLayout when only the relayout boundary is different
#99056
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
Avoid calling performLayout when only the relayout boundary is different
#99056
Conversation
bd50354 to
b1ffd1e
Compare
74050d8 to
51ef6ff
Compare
…ut-on-relayout-boundary-changes
51ef6ff to
f506e5f
Compare
goderbauer
left a comment
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.
LGTM
| set layoutCount(int newValue) { | ||
| renderObject.layoutCount = newValue; | ||
| } |
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.
Do you need this setter? Maybe remove it since it is a bit doggy.
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'd probably also remove the getter as well and just obtain the current layoutCount value in the test with tester.renderObject<RenderLayoutCount>(find.byType(RenderLayoutCount)).layoutCount. Currently the test reads a little strange with getting the layoutCount off a widget...
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.
Switched to WidgetToRenderBoxAdapter instead
…ut-on-relayout-boundary-changes
In theory a render subtree shouldn't redo its layout if the incoming constraints are the same and nothing in the tree is dirty. Whether a node is a relayout boundary (or who its relayout boundary is) isn't really "inherent" and shouldn't affect the subtree's layout.
This pull request:
RenderObject.layoutfrom aggressively marking everything dirty in a subtree until the next relayout boundary is reached (instead mark everything dirty until the closest known repaint boundary inRenderObject.markNeedsLayout).Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.