-
Notifications
You must be signed in to change notification settings - Fork 6k
Platform views have CreateExternalViewEmbedder #22214
Conversation
|
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat. Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
37247cc to
b16d861
Compare
d05ba89 to
47871c3
Compare
chinmaygarde
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.
I'd prefer we stayed away from shared pointers unless there are components that are shared across threads. Shared ownership of the object makes its lifetime hard to ascertain and the object has to make sure we its destruction is safe on any thread. We usually don't have components that do that.
In this case, it looks like the external view embedder is only used on the raster thread. So maybe the platform call to create the external view embedder can return a shared pointer instead.
On a related note, the CreateExternalViewEmbedder method makes it seem like a new instance will be allocated, but platform views are free to return a reference to an existing instance. That confused me a bit. Not sure what else to call it though. Maybe just document this? If you avoid shared pointers, this problem goes away too.
Did you mean a In the current world it's still shared with the surface. Though they are still accessed on the raster thread. But as I mentioned earlier, this will soon be simplified. |
|
Also, create is a misleading name. I agree, I initially wanted to call this |
|
@chinmaygarde friendly ping on this. |
gaaclarke
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.
Looks good for the most part my 2 big concerns are:
- The added method says
CreateExternalViewEmbedderbut none of the implementations actually create anything. - It's worth seeing if we can make the external view embedder a constructor argument to the rasterizer. I'm not sure it's easily possible, please take a look.
shell/common/rasterizer.cc
Outdated
| if (surface_ != nullptr && surface_->GetExternalViewEmbedder() != nullptr) { | ||
| surface_->GetExternalViewEmbedder()->EndFrame(should_resubmit_frame, | ||
| raster_thread_merger_); | ||
| if (surface_ && external_view_embedder_) { |
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 still want to predicate this on surface_? Looks like it should work without 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.
Done!
shell/common/rasterizer.cc
Outdated
| void Rasterizer::SetExternalViewEmbedder( | ||
| const std::shared_ptr<ExternalViewEmbedder>& view_embedder) { | ||
| external_view_embedder_ = view_embedder; | ||
| } | ||
|
|
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.
Could we make the external_view_embedder_ a parameter to the constructor instead of setting it later? That would be safer.
| // |PlatformView| | ||
| std::shared_ptr<ExternalViewEmbedder> | ||
| PlatformViewAndroid::CreateExternalViewEmbedder() { | ||
| return external_view_embedder_; | ||
| } | ||
|
|
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 name of this method is CreateExternalViewEmbedder, but this method is not creating one, it's just returning one that is already created. We should change the name of the method, or change the implementation.
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.
@gaaclarke I agree with this, please look at #22214 (comment). I will rename this method to GetExternalViewEmbedder once #22272 lands.
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.
Edit: I agree with your #22214 (comment). Once we don't have to share the external view embedder with surfaces, I will make this a unique_ptr and make rasterizer the sole owner. CreateExternalViewEmbedder makes sense in that world for sure!
I just read Chinmay's feedback. It seems like the sole owner for the external view embedder should be the rasterizer, then you can keep the semantics of |
|
@gaaclarke I've looked through passing That being said, I do agree that rasterizer being the sole-owner for EVE is a world that we should go towards, and I will get to it as part of: flutter/flutter#69905 |
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 with the promise that the shared_ptr will get removed and the method CreateExternalViewController will be reconsidered after the other PR lands.
|
I wish github did dependent PRs better so we could approve all your steps before they land. It makes me a bit nervous landing code that we know we want to change right away. |
|
This pull request is not suitable for automatic merging in its current state.
|
|
This might need to be rebased to make the failing presubmit pass. |
This is the last change before we can remove GetExternalViewEmbedder from the Surface APIs. This furthers the effort to share the surfaces between macOS and iOS.
8dbd0f4 to
731180a
Compare
This is the last change before we can remove GetExternalViewEmbedder from the Surface APIs.
This furthers the effort to share the surfaces between macOS and iOS.