The view was being accessed from a background thread so its OpenGL context could be accessed. This tripped thread safety assertions in Cocoa. Now the OpenGL context is stashed in the FlutterEngine instance itself.
Since this is currently only meant to be used by the embedding internally, the setter in Objective-C is only exposed via the FlutterDartProject private class extension. Unit tests have been added to the shell_unittests harness.
Fixes https://github.com/flutter/flutter/issues/37641
Texture unregistration is finished on the GPU thread. The FlutterTexture implementation might not know when it is finished which leads to a race condition. Adding this callback so the FlutterTexture is aware of end of the unregistration process.
* Added some thread asserts to the code and made ios_surface_ safe since
its being written and read from different threads.
* responded to chinmays feedback, added comment
This reverts commit c2879cae2ee3707ad07af1118bf4862dc1d82bb7.
Additionally, we fix https://github.com/flutter/flutter/issues/40863 by adding a secondary VSYNC callback.
Unit tests are updated to provide VSYNC mocking and check the fix of https://github.com/flutter/flutter/issues/40863.
The root cause of having https://github.com/flutter/flutter/issues/40863 is the false assumption that each input event must trigger a new frame. That was true in the framework PR https://github.com/flutter/flutter/pull/36616 because the input events there are all scrolling move events. When the PR was ported to the engine, we can no longer distinguish different types of events, and tap events may no longer trigger a new frame.
Therefore, this PR directly hooks into the `VsyncWaiter` and uses its (newly added) secondary callback to dispatch the pending input event.
Started asserting the FlutterEngine is running before communicating
over channels. This changes a null pointer exception to an
NSException that will provide some meaningful data to clients
incorrectly using the engine in an add-to-app situations.
Made creating and using a FlutterEngine a bit easier, to try to get it get it as easy to use as Android's equivalent.
* Added a default entrypoint variable.
* I added `run` to and `initWithName:` to FlutterEngine.
Manage resource and onscreen contexts using separate IOSGLContext objects.
FlutterView owns the onscreen context, and PlatformViewIOS owns the resource context.
Additionally, we now use the engine directly as a delegate instead of storing potentially dead runtime_controller.
Unit tests have been updated to include an engine restart check which would fail before the fix.
This fixes https://github.com/flutter/flutter/issues/40303
Creates a starting point for an app delegate. For now it just
incorporates the menu and window renaming functionality that's currently
in the FDE example, but in the future this will also do forwarding of
application lifecycle events to plugins.
Fixes https://github.com/flutter/flutter/issues/32419
