-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Introduce the PipelineOwner tree #122231
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
Introduce the PipelineOwner tree #122231
Conversation
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.
| /// [PipelineOwner]s can be organized in a tree to manage multiple render trees, | |
| /// [PipelineOwner]s are organized in a tree to manage multiple render trees, |
Aren't they always arranged this way (even a single main view can have subviews).
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 wanted to express here that the PipelineOwner class can also be used stand-alone. It fully functions if it is not part of a tree, for example for the use case mentioned above where you create another pipeline owner to manage off-screen objects. You are not required to turn them into a tree or attach them to any (existing) tree. Of course, one could argue, that just having a single node (the root) is also a form of tree...
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.
Oh, OK, ignore my comment then.
Of course, one could argue, that just having a single node (the root) is also a form of tree...
We don't need to be as pedantic as all that. :-)
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.
| bool _debugDoingChildrenLayout = false; | |
| bool _debugDoingChildLayout = false; |
...because it just reads better. I'd either say "I'm doing child layout" or "I'm laying out children", but not "I'm doing children 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.
| /// which this owner is connected to has [PipelineManifold.enableSemantics] | |
| /// which this owner is connected has [PipelineManifold.enableSemantics] |
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.
Maybe wrap this line
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.
| /// the parent [PipelineOwner] will complete a phase first for the nodes it | |
| /// the parent [PipelineOwner] will complete a phase for the nodes it |
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.
Why use adopt/drop? They're not really opposites of each other. Why not addChild/removeChild? If you want to use adopt, then the opposite is probably "abandon". Which feels a bit bleak. :-)
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.
That's the terminology we use for every other tree node class in the framework:
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.
Sigh. Okay, consistency is important, but it's too bad that they aren't opposites.
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.
Agreed!
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 really like that name.
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.
| /// by passing it to [PipelineOwner.attach]. Children are attached to the same | |
| /// by passing the manifold to [PipelineOwner.attach]. Children are attached to the same |
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.
| /// Called be a [PipelineOwner] connected to this [PipelineManifold] when a | |
| /// Called by a [PipelineOwner] connected to this [PipelineManifold] when a |
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.
maybe link RenderObject?
| /// render object associated with that pipeline owner wishes to update its | |
| /// [RenderObject] associated with that pipeline owner wishes to update its |
0889d78 to
e1220e7
Compare
448e790 to
fb46684
Compare
|
All comments are addressed and all failing checks should pass now. PTAL @gspencergoog. |
gspencergoog
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.
83448f5 to
a514117
Compare
|
It looks like this PR is causing failures in the tree: https://ci.chromium.org/ui/p/flutter/builders/prod/Linux%20web_canvaskit_tests_7_last/7125/overview |
Introduce the PipelineOwner tree
This reverts commit 670f9d2.

Part of #121573.
Implements the PipelineOwner tree as specified in https://flutter.dev/go/multiple-views.