-
Notifications
You must be signed in to change notification settings - Fork 6k
implemented GetMainContext() for opengl #23634
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -7,6 +7,7 @@ | |
| #import <OpenGLES/EAGL.h> | ||
|
|
||
| #include "flutter/shell/common/shell_io_manager.h" | ||
| #include "flutter/shell/gpu/gpu_surface_gl.h" | ||
| #include "flutter/shell/gpu/gpu_surface_gl_delegate.h" | ||
| #import "flutter/shell/platform/darwin/ios/ios_external_texture_gl.h" | ||
|
|
||
|
|
@@ -24,7 +25,11 @@ | |
| } | ||
| } | ||
|
|
||
| IOSContextGL::~IOSContextGL() = default; | ||
| IOSContextGL::~IOSContextGL() { | ||
| if (main_context_) { | ||
| main_context_->releaseResourcesAndAbandonContext(); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't know if it's possible. The various GPUSurfaceGL still has this shared pointer right? Could there be any risks? |
||
| } | ||
| } | ||
|
|
||
| std::unique_ptr<IOSRenderTargetGL> IOSContextGL::CreateRenderTarget( | ||
| fml::scoped_nsobject<CAEAGLLayer> layer) { | ||
|
|
@@ -45,12 +50,11 @@ | |
|
|
||
| // |IOSContext| | ||
| sk_sp<GrDirectContext> IOSContextGL::GetMainContext() const { | ||
| /// TODO(73744): Currently the GPUSurfaceGL creates the main context for | ||
| /// OpenGL. With Metal the IOSContextMetal creates the main context and is | ||
| /// shared across surfaces. We should refactor the OpenGL Context/Surfaces to | ||
| /// behave like the Metal equivalents. Until then engines in the same group | ||
| /// will have a heavier memory cost if they are using OpenGL. | ||
| return nullptr; | ||
| return main_context_; | ||
| } | ||
|
|
||
| void IOSContextGL::SetMainContext(const sk_sp<GrDirectContext>& main_context) { | ||
| main_context_ = main_context; | ||
| } | ||
|
|
||
| // |IOSContext| | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -38,8 +38,16 @@ | |
| std::unique_ptr<Surface> IOSSurfaceGL::CreateGPUSurface(GrDirectContext* gr_context) { | ||
| if (gr_context) { | ||
| return std::make_unique<GPUSurfaceGL>(sk_ref_sp(gr_context), this, true); | ||
| } else { | ||
| IOSContextGL* gl_context = CastToGLContext(GetContext()); | ||
| sk_sp<GrDirectContext> context = gl_context->GetMainContext(); | ||
| if (!context) { | ||
| context = GPUSurfaceGL::MakeGLContext(this); | ||
| gl_context->SetMainContext(context); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ditto here. Seems like we have 2 timing characteristics. The metal case just makes this GrDirectContext way earlier when creating the shell's on_create_platform_view, whereas this makes it way later in FlutterViewController's viewWillAppear. There could be minutes in between if the engine was prewarmed. I'm a bit worried that there might be side-effects involving platform views or memory etc that are hard to reproduce due to the rendering API differences. It doesn't have to be in this PR, but I suppose this way works better memory wise. Can we make metal work this way too? Though on the flip side, this likely shifts more of the latency away from the engine prewarming into the critical path for showing the first frame. |
||
| } | ||
|
|
||
| return std::make_unique<GPUSurfaceGL>(context, this, true); | ||
| } | ||
| return std::make_unique<GPUSurfaceGL>(this, true); | ||
| } | ||
|
|
||
| // |GPUSurfaceGLDelegate| | ||
|
|
||
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.
If possible, can we add some consistency between the metal version and this one? In metal, the IOSContextMetal just decides to make a GrDirectContext the way it wants without asking anyone. Here, it seems like the IOSSurfaceGL asks the GPUSurfaceGL to make one, then pushes it into IOSContextGL which then owns it.