For this to work, we need to provide our own capture scope otherwise the default scope won't capture our commands.
This is required as part of the work to switch to unmerged threads for PVs (https://github.com/flutter/engine/pull/53826), as I can confirm @knopp 's observations that the performance is much worse with the default CAMetalLayer.
Fixes https://github.com/flutter/flutter/issues/140901
This removes support for "unobstructed platform views" on iOS - instead prefering to use the Android strategy of minimizing overlay layers, as this is generally more performant.
The name was confusing, as it only provided one type of backing store.
FlBackingStoreProvider sounds more like an interface that the
FlFramebuffer would implement if we had multiple backing stores.
Use OpenGL types for values.
Fix cases where this was sometimes called a texture.
Improve documentation.
Remove the use of GdkRectangle for dimensions - the framebuffer only has
a width and a height. There was code that was using the x,y values which
would always have been zero - this has now been removed.
`FlutterPlatformViewLayerPool` is a pool of iOS layers used for rendering platform views on iOS. When layers are no longer needed, we currently mark them available for re-use but we never actually flush them and thus recover the memory associated with these layers once we know that the layers are no longer needed.
We now flush the layer pool on `SubmitFrame` if a previously-used layer is no longer used in the current frame. In theory, this could cause a performance regression in the case where an additional layer is needed every second or third frame, but we should keep it simple on the first pass and only complicate things later if warranted.
Fixes: https://github.com/flutter/flutter/issues/152053
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This decouples the Impeller on-by-default effort from the release schedule and [plugin migrations](https://github.com/flutter/flutter/issues/151018).
The plugin migration documented in [go/impeller-plugin-migration][plugin-migration] is still recommended and facilitates zero-copy texture transfers between OpenGL and Vulkan. To recap, the plugin migration is to move away from the OpenGL-only SurfaceTexture APIs in the plugin interface.
This patch facilitates rendering OpenGL textures in a Vulkan renderer using texture trampolining using a single device-device transfer on all devices that support Impeller using the Vulkan renderer.
The performance of this approach is more than acceptable but at the cost of an additional texture allocation and will serve as a fallback to the for any remaining unmigrated plugins (all first-party plugins will already be migrated when the Impeller is on by default and we are following up on the migration of the major third-party plugins as well).
This is a straight improvement to the current state of things were unmigrated plugins will render an empty quad.
This is API that will be required when we get multi-view support on
Linux. While this internal API is not currently used, I've made a PR so
it can be more easily reviewed.
The Linux embedder had a number of handlers for Flutter channels that
were named plugin/handler/manager. Rename these all to handler to be
consistent and reduce confusion with Flutter plugins (which these don't
use the infrastructure for).
The Dart SDK's `package:async_helper/async_minitest.dart` was never intended for new tests, it was a drop-in polyfill for the legacy `package:unit_test` that some Dart SDK tests were using. The tests should never have used that package, and migrating them to `package:test` was not an option, so the `async_minitest.dart` file was the minimal polyfill that made all the tests run.
Since then, new tests have been written using the file, and to stop that, the file will now become deprecated, and (hopefully some day) removed.
If the Flutter engine wants to keep using the file, they should own their own copy of it, which is what this change does.
(Also migrates off the to-be-deprecated `assertStatementsEnabled` property of `package:expect/expect.dart`, moved to the new `asserts` from `package:expect/variations.dart`.)
No change in functionality. The updates:
* HeaderDoc comments have been added to the major rendering related TUs. However, not all comments are complete. I only documented the stuff I understood. For instance, it isn't clear how/why some subclasses use Attach/Detach while other use ProcessFrame. I intend to document as I go.
* Each package specific subclass is now in its own TU.
* Some subclasses used to be Skia specific. We added an Impeller variant but didn't rename to Skia TU. This has been patched.
This PR makes the macOS `FlutterCompositor` able to handle multiple views by adding methods `AddView` and `RemoveView`.
These two methods must take place on the main queue (platform thread), which is indeed the case, but extra effort is made to assert so. This is important because, due to the constraint of the macOS system that requires rendering to take place on the platform thread (hence `FlutterThreadSynchronizer`), no locks are needed to avoid race condition between `Add/RemoveView` and presenting.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Experimentally support merging UI and platform thread on Android/iOS. This works by changing the shell holder to set the UI thread to the platform thread. Several shell APIs that post messages from the platform to ui thread were changed to use RunNowOrPostTask to immediately call the UI task if the threads are the same.
Experimentally, this seems to work reasonably well if there are no platform views. On Android with TLHC it works fine either way, while iOS currently takes a big performance hit.
This can be opted into via a Plist:
```
<key>FLTEnableMergedPlatformUIThread</key>
<true/>
```
Or via AndroidManifest.xml:
```
<meta-data
android:name="io.flutter.embedding.android.EnableMergedPlatformUIThread"
android:value="true" />
```
https://github.com/flutter/flutter/issues/150525
Fixes https://github.com/flutter/flutter/issues/151274
This is only an issue on iOS (so far) because of the platform view rendering strategy that involves submitting multiple impeller frames per compositor frame.
FYI @bdero
Due to changes in the renderer in fc560d4 the engine was created once a
widget is realized, not when the widget is created. If a Flutter
application changed the default my_application.cc template to show the
Flutter widget after plugins are run then these plugins would not be
able to access the engine.
Solved by removing the GdkWindow from the renderer constructor and
setting in later when the widget is realized. This works because the
renderer is not used until the widget is realized.
Fixes https://github.com/flutter/flutter/issues/144873
Almost working bdf for experimentcal canvas.
Currently there are some problems with the clip depth, and positioning of the backdrop filter. I think I am not taking the blur transform into account at the very least.
FYI @bdero
Previously CreateEGLImage had been failing an assertion if an EGL display is not active on the calling thread. CreateEGLImage should not assert here because it could be called from a deferred task that runs after the raster thread has lost its EGL state.
See https://github.com/flutter/flutter/issues/149396
When `FlutterUndoManagerPlugin` deallocated, it is supposed to deregister itself from the `NSUndoManager` stack.
However, during dealloc `_undoManagerDelegate.undoManager` is nil (`_undoManagerDelegate` = the engine, and `undoManager` was its view controller's `undoManager`, which was already gone).
Since `_undoManagerDelegate.undoManager` is nil, it doesn't actually call `-[NSUndoManager removeAllActionsWithTarget]`. In the add-to-app scenario, after the view controller pops back to the native view, and "undo" is invoked, the undo action for the `FlutterUndoManagerPlugin` is handled, but it already dealloced so crash.
Fixes https://github.com/flutter/flutter/issues/150408
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The Vertices objects are already allocated in a shared object by default so copying them inline into the recording buffer is usually a waste of time rather than reusing the memory allocated for the shared object by recording a reference. Note that the shared DlVertices objects already inline all of their data so we have good data locality as it is without further copying the data into the buffer.
Might help with https://github.com/flutter/flutter/issues/150513
