-
Notifications
You must be signed in to change notification settings - Fork 6k
Multiview ExternalViewEmbedder #46169
Conversation
09a6e77
to
e095f1f
Compare
08e8ff1
to
c7d5022
Compare
flow/embedded_views.h
Outdated
// | ||
// 1. At the start of a frame, call |BeginFrame|, then |SetUsedThisFrame| to | ||
// true. | ||
// 2. For each view to be drawn, call |PrepareView|, then |SubmitView|. |
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.
View versus platform view is confusing. Would it be better to refer to views that back Flutter content as "Flutter views"?
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 status is:
- There are "native views". As defined above, each native view corresponds to a window (simply put).
- The content for each native view is composited from a layer tree.
- Layer trees have types, platform view layer being one of them.
- I'm not sure if a "flutter view" is the complement for "platform view".
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 would be tempted to use the term Flutter View and Platform View explicitly where there's any possibility for confusion.
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 changed the names to PrepareFlutterView
SubmitFlutterView
flutter_view_id
and platform_view_id
.
SkISize frame_size, | ||
double device_pixel_ratio) { | ||
// TODO(dkwingsmt): This class only supports rendering into the implicit view. | ||
// Properly support multi-view in the future. |
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 we have a tracking issue for this? I'm assuming this affects macOS, so we'll want to fix this as part of the desktop multi-view project.
(In theory we should have a tracking issue for IOSExternalViewEmbedder::PrepareView
too but I don't feel as strongly about that one!)
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.
Yeah I'll link flutter/flutter#135530 item 4 to it. (Although I'll submit the PR for embedder API that removes this TODO.)
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.
These changes LGTM but I'm not familiar enough with this area to approve. Please loop in reviewers from the engine team too
shell/common/rasterizer.cc
Outdated
(!raster_thread_merger_ || raster_thread_merger_->IsMerged())) { | ||
FML_DCHECK(!frame->IsSubmitted()); | ||
external_view_embedder_->SubmitFrame( | ||
external_view_embedder_->SubmitView( |
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, I thought this frame was like the "frame" as in "144 frames per second".
flow/embedded_views.cc
Outdated
} | ||
|
||
void ExternalViewEmbedder::SubmitFrame( | ||
void ExternalViewEmbedder::SubmitView( |
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 wonder if there's a clearer name for this that isn't overly long -- SubmitViewFrame
for example?
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 wonder how much we need to mention "frame" in this context, since of course a view is part of a frame, and the relationship is also explained in the lifecycle described in ExternalViewEmbedder
's doc.
If we really need it, maybe FrameSubmitView
is better, since it shows that the view is part of a frame. What do you think?
I also added a paragraph to |
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.
Overall this seems like a reasonable refactoring to decouple frame lifecycle from the individual surface work in terms of the approach that was proposed to this.
Please also request a review from @chinmaygarde or another relevant person from the core engine team for feedback.
double device_pixel_ratio, | ||
const fml::RefPtr<fml::RasterThreadMerger>& raster_thread_merger) { | ||
TRACE_EVENT0("flutter", "ExternalViewEmbedder::BeginFrame"); | ||
} |
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.
Remove the trace event - it's pure overhead at this point, measuring an empty function.
double device_pixel_ratio, | ||
const fml::RefPtr<fml::RasterThreadMerger>& raster_thread_merger) { | ||
TRACE_EVENT0("flutter", "IOSExternalViewEmbedder::BeginFrame"); | ||
} |
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.
Ditto - remove this trace event, this method should just be empty now.
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.
Please remove the tracing on empty method bodies, otherwise LGTM
…139507) flutter/engine@c6395d9...de0ba84 2023-12-04 skia-flutter-autoroll@skia.org Roll Skia from 0fe76d9ce79e to cbd2cf40d63b (1 revision) (flutter/engine#48638) 2023-12-04 dnfield@google.com Remove some trivial forward declares from Impeller (flutter/engine#48635) 2023-12-04 737941+loic-sharma@users.noreply.github.com [Windows] Decouple the GL context from the view (flutter/engine#48636) 2023-12-04 dkwingsmt@users.noreply.github.com Multiview ExternalViewEmbedder (flutter/engine#46169) 2023-12-04 skia-flutter-autoroll@skia.org Roll Dart SDK from 67f7a2c2559a to a1b67665b3a3 (1 revision) (flutter/engine#48637) 2023-12-04 skia-flutter-autoroll@skia.org Roll Skia from db4a29e0689e to 0fe76d9ce79e (5 revisions) (flutter/engine#48634) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Please CC matanl@google.com,rmistry@google.com,zra@google.com on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://issues.skia.org/issues/new?component=1389291&template=1850622 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
This PR connects the view ID provided by the rasterizer to `EmbedderExternalViewEmbedder`'s presenting call (see `embedder_external_view_embedder.cc`). This PR also contains a refactor (which actually takes the majority of LOC) that moves the specification of view ID from `PrepareFlutterView` to `SubmitFlutterView`. The `flutter_view_id` parameter in `PrepareFlutterView` was added in #46169. It turns out that we don't need the view ID throughout the preparation phase, so we can delay the specification to submission, which makes it feel cleaner. ### Tests Existing tests are changed to verify that `SubmitFlutterView` receive the correct view ID. The feature that `EmbedderExternalViewEmbedder` sends the view ID to the presenting API is not tested for now, because `EmbedderExternalViewEmbedder` is typically tested in `embedder_unittests`, but it requires the embedder API `AddView`. It will be tested in later changes to `EmbedderExternalViewEmbedder`. [C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This PR adds multiview support for
ExternalViewEmbedder
.Nomenclature
The term view can be ambiguous in
ExternalViewEmbedder
, and therefore the following terms are used:Shell::AddView
.Change
The lifecycle of
ExternalViewEmbedder
is changed:BeginFrame
should perform per-frame actions, such as merge-unmerging threads.PrepareView
should perform per-native-view preparations, such as recording the view ID and view size.This change is necessary because some actions in
PrepareView
needs to be refreshed at the beginning of drawing every native view.Pre-launch Checklist
///
).If you need help, consider asking for advice on the #hackers-new channel on Discord.