Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.

Conversation

@iskakaushik
Copy link
Contributor

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.

@flutter-dashboard
Copy link

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.

@iskakaushik iskakaushik force-pushed the pv_c_ext_embe-2 branch 2 times, most recently from 37247cc to b16d861 Compare October 30, 2020 00:06
@iskakaushik iskakaushik changed the title Platform views have GetExternalViewEmbedder Platform views have CreateExternalViewEmbedder Oct 30, 2020
Copy link
Member

@chinmaygarde chinmaygarde left a 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.

@iskakaushik
Copy link
Contributor Author

So maybe the platform call to create the external view embedder can return a shared pointer instead.

Did you mean a unique_ptr instead? My plan is to go to a world where we have only one instance of the external view embedder. And that is held by the rasterizer and briefly passed to the compositor context as a raw pointer to acquire frame, etc.

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.

@iskakaushik
Copy link
Contributor Author

Also, create is a misleading name. I agree, I initially wanted to call this GetExternalViewEmbedder as all the platforms typically have this created and just return an instance. There were name conflicts where some of the platform views were themselves extending the GpuSurfaceDelegate interface and lead to name conflicts.

@iskakaushik
Copy link
Contributor Author

@chinmaygarde friendly ping on this.

Copy link
Member

@gaaclarke gaaclarke left a 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:

  1. The added method says CreateExternalViewEmbedder but none of the implementations actually create anything.
  2. 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.

if (surface_ != nullptr && surface_->GetExternalViewEmbedder() != nullptr) {
surface_->GetExternalViewEmbedder()->EndFrame(should_resubmit_frame,
raster_thread_merger_);
if (surface_ && external_view_embedder_) {
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done!

Comment on lines 653 to 657
void Rasterizer::SetExternalViewEmbedder(
const std::shared_ptr<ExternalViewEmbedder>& view_embedder) {
external_view_embedder_ = view_embedder;
}

Copy link
Member

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.

Comment on lines +310 to +315
// |PlatformView|
std::shared_ptr<ExternalViewEmbedder>
PlatformViewAndroid::CreateExternalViewEmbedder() {
return external_view_embedder_;
}

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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!

@gaaclarke
Copy link
Member

If you avoid shared pointers, this problem goes away too.

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 CreateExternalViewEmbedder. That sounds like a better solution and eliminates the shared_ptr.

@iskakaushik
Copy link
Contributor Author

@gaaclarke I've looked through passing ExternalViewEmbedder (EVE) as a ctor param for the rasterizer. Across most of the platforms EVE is owned as a shared_ptr by the platform view. There needs to be a refactor that moves the creation to engine or the equivalent and passed to on_create_rasterizer.

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

Copy link
Member

@gaaclarke gaaclarke left a 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.

@gaaclarke
Copy link
Member

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.

@iskakaushik iskakaushik added the waiting for tree to go green This PR is approved and tested, but waiting for the tree to be green to land. label Nov 5, 2020
@fluttergithubbot
Copy link
Contributor

This pull request is not suitable for automatic merging in its current state.

  • The status or check suite build_and_test_linux_unopt_debug has failed. Please fix the issues identified (or deflake) before re-applying this label.

@fluttergithubbot fluttergithubbot removed the waiting for tree to go green This PR is approved and tested, but waiting for the tree to be green to land. label Nov 5, 2020
@chinmaygarde
Copy link
Member

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.
@iskakaushik iskakaushik added the waiting for tree to go green This PR is approved and tested, but waiting for the tree to be green to land. label Nov 6, 2020
@iskakaushik iskakaushik merged commit 6e95e00 into flutter:master Nov 6, 2020
@iskakaushik iskakaushik deleted the pv_c_ext_embe-2 branch November 6, 2020 13:30
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

cla: yes platform-android platform-ios waiting for tree to go green This PR is approved and tested, but waiting for the tree to be green to land.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants