-
Notifications
You must be signed in to change notification settings - Fork 6k
Manage resource and onscreen contexts using separate IOSGLContext objects #11798
Conversation
…ation. minor style updates. release onscreenContext at FlutterView destruction
| @implementation FlutterView | ||
|
|
||
| id<FlutterViewEngineDelegate> _delegate; | ||
| std::shared_ptr<flutter::IOSGLContext> _onscreenContext; |
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.
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
|
So I'm in the process of running this through @xster's testcase and it looks like it's still leaking the |
…way. Refcounting fixes.
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.
Other than the leaky context, just nits.
shell/platform/darwin/ios/framework/Source/FlutterOverlayView.h
Outdated
Show resolved
Hide resolved
| opaque:(BOOL)opaque NS_DESIGNATED_INITIALIZER; | ||
| - (std::unique_ptr<flutter::IOSSurface>)createSurface: | ||
| (std::shared_ptr<flutter::IOSGLContext>)context; | ||
| (std::shared_ptr<flutter::IOSGLContext>)resourceContext; |
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.
Same comment about the ObjC naming convention.
- 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
…nstead, as per existing convention
dnfield
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.
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 { |
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.
nit: these should be onscreenGLContext and resourceGLContext respectively
shell/platform/darwin/ios/framework/Source/FlutterPlatformViews_Internal.h
Show resolved
Hide resolved
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.
Other than the nit about the target argument not being used, looks good to me. Thanks.
| @implementation FlutterView | ||
|
|
||
| id<FlutterViewEngineDelegate> _delegate; | ||
| @implementation FlutterView { |
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.
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.
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.
dnfield
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.
LGTM
|
This is causing build failures on LUCI. |
…text objects (flutter#11798)" This reverts commit a353f93.
|
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? |
|
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? |
|
Yes, building locally worked (I loaded the Xcode project locally and built
it and ran it on device). I will back out the change and sort it out on
Monday.
…On Fri, Sep 6, 2019 at 6:20 PM Kaushik Iska ***@***.***> wrote:
I had a similar thing happen to me a few days ago. I filed
flutter/flutter#39336 <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?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#11798?email_source=notifications&email_token=AAJKDQIXRZYM7MAXFHIGWFTQIL6UXA5CNFSM4ISRY7C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6EMYJY#issuecomment-529058855>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJKDQLDSYSMWUWNABZ2RK3QIL6UXANCNFSM4ISRY7CQ>
.
--
You received this message because you are subscribed to the Google Groups
"gw280" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ***@***.***
|
|
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 |
|
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. |
…ects (flutter#11798) Manage resource and onscreen contexts using separate IOSGLContext objects
…ects (flutter#11798) Manage resource and onscreen contexts using separate IOSGLContext objects
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.