This reverts commit f456423cfb820d07bb36e9a8979e3d75cc9d8d76.
This is being reverted because it caused flutter/flutter#45098
(images don't load on iOS).
* Guard against orphaned semantic objects trying to reference a dead bridge on iOS.
* Switched back to a function instead of a macro for checking the bridge.
* Fixed some formatting issues.
This fixes the selection and deletion during text editing on macOS so that it can handle selections that have a base (selection start) that is after the extent (selection end) in the string.
Apparently the insertText:replacementRange on macOS can supply an NSRange object that has negative values for the length (even though the length is an unsigned NSUInteger). This change checks for that case, and fixes the range of characters replaced in the text to have the right bounds.
Also, I added an additional updateEditState after the state is set from the framework, since there is a timing problem: when the delete key is pressed, it sends an insertText message, which updates the framework state after the framework has already sent its state update to delete the selected region. This additional updateEditState puts the engine and framework back in sync again. Ideally, we would just avoid sending the insertText message, but there's really no way for the engine to know if the pressed key is part of an edit sequence or not.
When gr context is changed (this happens when sending the app to the background and then to the foreground) we need to update it for all the platform view overlay surfaces.
The update logic was caching the previous gr context to figure if it had to be updated, but after updating it for a given overlay we were updating the cached context. In apps with multiple platform views this will result in overlays with a stale gr context.
This fixesflutter/flutter#36437
And I believe it should fixflutter/flutter#36999 as well (though I don't have repro code to verify).
Having 2 or more platform views simultaneously in the layer tree was crashing immediately on iOS with GL backend.
This regressed in #11070 which passed gl_context to a function in a loop using std::move (which meant on the second iteration the caller is no longer the owner of the field).
I added a scenarios_app test, though this test doesn't run on a physical device on CI so it would have only caught the problem when running locally (flutter/flutter#43852).
This used to only be handled correctly for non-root layer backing stores. This
was mostly a side effect of the fact that we used recording canvases instead of
rendering directly into the backing store. We now use recording canvases
consistently.
Fixes b/143464703
Fixes https://github.com/flutter/flutter/issues/43732
Also creates a new test harness for the desktop embedder framework target and adds a test that launches a headless engine in this new thread configuration.
Fixes https://github.com/flutter/flutter/issues/17579
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
