Skip to content
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

Merged
merged 12 commits into from Mar 10, 2023
Merged

Conversation

goderbauer
Copy link
Member

Part of #121573.

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

@flutter-dashboard flutter-dashboard bot added a: tests "flutter test", flutter_test, or one of our tests framework flutter/packages/flutter repository. See also f: labels. labels Mar 8, 2023
@@ -859,6 +859,20 @@ class _LocalSemanticsHandle implements SemanticsHandle {
/// are visible on screen. You can create other pipeline owners to manage
/// off-screen objects, which can flush their pipelines independently of the
/// on-screen render objects.
///
/// [PipelineOwner]s can be organized in a tree to manage multiple render trees,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// [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).

Copy link
Member Author

@goderbauer goderbauer Mar 9, 2023

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...

Copy link
Contributor

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. :-)

@@ -945,6 +967,7 @@ class PipelineOwner {
/// always returns false.
bool get debugDoingLayout => _debugDoingLayout;
bool _debugDoingLayout = false;
bool _debugDoingChildrenLayout = false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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".

/// [semanticsOwner] field will revert to null, and the previous owner will be
/// disposed.
/// An owner is created by [ensureSemantics] or when the [PipelineManifold] to
/// which this owner is connected to has [PipelineManifold.enableSemantics]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// which this owner is connected to has [PipelineManifold.enableSemantics]
/// which this owner is connected has [PipelineManifold.enableSemantics]

_updateSemanticsOwner();

// If onNeedVisualUpdate is specified, it has already been called when the node was dirtied in the first place.
if (onNeedVisualUpdate == null && (_nodesNeedingLayout.isNotEmpty || _nodesNeedingCompositingBitsUpdate.isNotEmpty || _nodesNeedingPaint.isNotEmpty || _nodesNeedingSemantics.isNotEmpty)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe wrap this line

/// Adds `child` to this [PipelineOwner].
///
/// During the phases of frame production (see [RendererBinding.drawFrame]),
/// the parent [PipelineOwner] will complete a phase first for the nodes it
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// the parent [PipelineOwner] will complete a phase first for the nodes it
/// the parent [PipelineOwner] will complete a phase for the nodes it

///
/// No children may be removed after the [PipelineOwner] has started calling
/// [flushLayout] on any of its children until the end of the current frame.
void dropChild(PipelineOwner child) {
Copy link
Contributor

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. :-)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed!

///
/// [PipelineOwner]s can register listeners with the [PipelineManifold] to be
/// informed when certain values provided by the [PipelineManifold] change.
abstract class PipelineManifold implements Listenable {
Copy link
Contributor

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.

/// particular binding implementation.
///
/// The root of the [PipelineOwner] tree is attached to a [PipelineManifold]
/// by passing it to [PipelineOwner.attach]. Children are attached to the same
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// 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

/// implementations typically use to back this property.
bool get semanticsEnabled;

/// Called be a [PipelineOwner] connected to this [PipelineManifold] when a
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// Called be a [PipelineOwner] connected to this [PipelineManifold] when a
/// Called by a [PipelineOwner] connected to this [PipelineManifold] when a

bool get semanticsEnabled;

/// Called be a [PipelineOwner] connected to this [PipelineManifold] when a
/// render object associated with that pipeline owner wishes to update its
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe link RenderObject?

Suggested change
/// render object associated with that pipeline owner wishes to update its
/// [RenderObject] associated with that pipeline owner wishes to update its

@goderbauer
Copy link
Member Author

All comments are addressed and all failing checks should pass now. PTAL @gspencergoog.

Copy link
Contributor

@gspencergoog gspencergoog left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

32384589-a60f0e74-c078-11e7-9bc1-e5b5287aea9d

@goderbauer goderbauer added the autosubmit Merge PR when tree becomes green via auto submit App label Mar 10, 2023
@auto-submit auto-submit bot merged commit f73c358 into flutter:master Mar 10, 2023
33 checks passed
@goderbauer goderbauer deleted the pipelineOwnerTree branch March 10, 2023 19:57
@flar
Copy link
Contributor

flar commented Mar 10, 2023

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

flar added a commit that referenced this pull request Mar 10, 2023
flar added a commit that referenced this pull request Mar 10, 2023
hangyujin pushed a commit to hangyujin/flutter that referenced this pull request Mar 11, 2023
hangyujin pushed a commit to hangyujin/flutter that referenced this pull request Mar 11, 2023
goderbauer added a commit to goderbauer/flutter that referenced this pull request Mar 11, 2023
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Mar 11, 2023
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Mar 12, 2023
auto-submit bot pushed a commit that referenced this pull request Mar 13, 2023
Reland "Introduce the PipelineOwner tree (#122231)"
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request May 10, 2023
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request May 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a: tests "flutter test", flutter_test, or one of our tests autosubmit Merge PR when tree becomes green via auto submit App framework flutter/packages/flutter repository. See also f: labels.
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

None yet

3 participants