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

Conversation

@gw280
Copy link
Contributor

@gw280 gw280 commented Aug 30, 2019

Initial attempt at managing the onscreen and resource GL contexts on iOS using separate IOSGLContext objects.

I still need to work out when to destroy the objects, but this seemed like a good place to get initial feedback.

My biggest concern with this patch is the static where I store the sharegroup to allow for the same sharegroup to be used to generate the contexts.

@gw280 gw280 requested a review from dnfield September 3, 2019 17:15
…ation.

minor style updates.

release onscreenContext at FlutterView destruction
@implementation FlutterView

id<FlutterViewEngineDelegate> _delegate;
std::shared_ptr<flutter::IOSGLContext> _onscreenContext;
Copy link
Member

Choose a reason for hiding this comment

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

thanks for renaming stuff too. This was always confusing to me.

- camelCase for objc variables
- switch to using a factory for creating contexts using the same sharedgroup -> hides implementation details of shared contexts from the caller
@gw280
Copy link
Contributor Author

gw280 commented Sep 3, 2019

So I'm in the process of running this through @xster's testcase and it looks like it's still leaking the IOSurface, so I'm investigating further.

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.

Other than the leaky context, just nits.

opaque:(BOOL)opaque NS_DESIGNATED_INITIALIZER;
- (std::unique_ptr<flutter::IOSSurface>)createSurface:
(std::shared_ptr<flutter::IOSGLContext>)context;
(std::shared_ptr<flutter::IOSGLContext>)resourceContext;
Copy link
Member

Choose a reason for hiding this comment

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

Same comment about the ObjC naming convention.

George Wright added 3 commits September 5, 2019 10:55
- Use WeakPtr to reference the onscreen/resource contexts outside of FlutterView
- FlutterView now explicitly owns the onscreen context through a unique_ptr
- (hacky for now - need to assess whether it's the right call) add a nullptr_t constructor for fml::WeakPtr
- ObjC naming convention nits
Copy link
Contributor

@dnfield dnfield left a comment

Choose a reason for hiding this comment

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

Seems like we're getting close. I haven't audited this for thread safety closely but nothing is jumping out as wrong, would defer to Chinmay on that one.

(std::shared_ptr<flutter::IOSGLContext>)gl_context {
- (std::unique_ptr<flutter::IOSSurface>)
createSurfaceWithOnscreenContext:(fml::WeakPtr<flutter::IOSGLContext>)onscreen_gl_context
resourceContext:(fml::WeakPtr<flutter::IOSGLContext>)resource_gl_context {
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: these should be onscreenGLContext and resourceGLContext respectively

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.

Other than the nit about the target argument not being used, looks good to me. Thanks.

@implementation FlutterView

id<FlutterViewEngineDelegate> _delegate;
@implementation FlutterView {
Copy link
Member

Choose a reason for hiding this comment

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

Can we file a bug to audit the codebase for existing issues like this? I the _delegate being static got past code review, there may be more instance of this kind of misuse.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

@dnfield dnfield left a comment

Choose a reason for hiding this comment

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

LGTM

@gw280 gw280 merged commit a353f93 into flutter:master Sep 6, 2019
@chinmaygarde
Copy link
Member

This is causing build failures on LUCI.

iskakaushik pushed a commit to iskakaushik/engine that referenced this pull request Sep 7, 2019
@xster
Copy link
Member

xster commented Sep 7, 2019

Can we add a note to https://github.com/flutter/flutter/wiki/Setting-up-the-Engine-development-environment or some such for how to run the LUCI tests locally before submitting until we have pre-submit LUCI tests on iOS?

iskakaushik added a commit that referenced this pull request Sep 7, 2019
@iskakaushik
Copy link
Contributor

I had a similar thing happen to me a few days ago. I filed flutter/flutter#39336 to re-enable iOS tests. The unfortunate situation is that MacStadium cirrus' provider for ios containers got so flaky that every test had to be triggered twice. It was a reasonable trade-off that we made at the time.

This looks like it was a compile failure -- I haven't dug into this too much. Did building locally work?

@gw280
Copy link
Contributor Author

gw280 commented Sep 7, 2019 via email

@chinmaygarde
Copy link
Member

Running LUCI tests locally is documented at go/flutter-luci#heading=h.80m6y2c7elmx. That test target does not use the GN build system and needs a specific engine variant to be built before invoking an extra step to build the test harness. So building just the iOS target and using run_tests.py would not have been sufficient anyway. @dnfield mentioned that this was going to be moved to use the GN build system and integrated with the rest of the build/test setup.

@dnfield
Copy link
Contributor

dnfield commented Sep 7, 2019

Chinmay's doc link is correct - and you'd need internal access AFAIK to run it, so not sure it makes sense to document publicly. We also have limited resources for running these right now - but that should change.

I'd be interested in seeing why this passed locally vs. CI, but my guesses are it may not have been run on the simulator locally, or that some warning wasn't enabled...

Once I get Fuchsia tests running I can work on wiring this up to GN. It might be a little funky because we need both host dart and the target framework/gen_snapshot to run these tests, but it should also make it clearer on how to run them on CI for physical devices.

engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Sep 7, 2019
gw280 added a commit to gw280/engine that referenced this pull request Sep 9, 2019
…ects (flutter#11798)

Manage resource and onscreen contexts using separate IOSGLContext objects
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Sep 9, 2019
gw280 added a commit to gw280/engine that referenced this pull request Sep 11, 2019
…ects (flutter#11798)

Manage resource and onscreen contexts using separate IOSGLContext objects
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Sep 11, 2019
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Sep 11, 2019
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Sep 11, 2019
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Sep 11, 2019
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Sep 12, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants