_`impeller.hpp` is to `impeller.h` what `vulkan.hpp` is to `vulkan.h`_
* A single header C++ 17 library that only depends on impeller.h and standard libc++ utilities.
* The C++ library proc. table is setup at runtime (via dlsym and related methods). Impeller users don't need to link against libimpeller.so as long as they can discover it at runtime.
* RAII wrappers for all opaque objects.
* Namespaces are configurable depending on target.
* Included in the distributed SDK next to impeller.h.
The Info.plist override was missed earlier.
The main changes to the tests are due to the UI thread merge with the platform thread. The amendment to the "spawn" API are due to the fact that the assertions checked for the presence of GrDirectContext which will never exist with Impeller.
Unblocks https://github.com/flutter/engine/pull/56706
Reverts: flutter/engine#56705
Initiated by: jonahwilliams
Reason for reverting: goldens occassionally fail to render anything.
Original PR Author: jonahwilliams
Reviewed By: {gaaclarke}
This change reverts the following previous change:
Adds multisampling support for GLES devices without GL_EXT_multisampled_render_to_texture provided they are at least GLES 3.0 to support mutlisampled render buffers.
Fixes https://github.com/flutter/flutter/issues/158360
Fixes https://github.com/flutter/flutter/issues/157951
TBD: should we prefer renderbuffer 3.0 approach over multisample_render_to_texture?
This PR introduces a `NativeAssetsManifest.json` next to the `AssetManifest.json` and `FontManifest.json`. This removes the need for embedding the native assets mapping inside the kernel file and will enable decoupling native assets building and bundling from the kernel compilation in flutter tools. This will then allow us to remove dry-run from the build hook protocol.
(It also means all isolate groups will have the same native assets. However, since Flutter does not support `Isolate.spawnUri` from kernel files anyways, this is not a regression.)
This manifest is parsed eagerly on startup by the engine in a manner similar to how the font manifest is parsed. The manifest contents need to be available in the callback for resolving assets, which does not have access to the engine. Therefore the parsed manifest is `NativeAssetsManager` stored in the `IsolateGroupData`. The engine passes it in on isolate group creation, and the FFI callbacks access it from the isolate group data.
Issue:
* https://github.com/flutter/flutter/issues/154425
Related PRs:
* https://dart-review.googlesource.com/c/sdk/+/388161
Follow up work:
* This PR does not yet remove the engine callbacks registered via the dart_api that rely on kernel embedding. If we were to do that in this PR, it would require a manual roll of the engine into flutter/flutter with the PR that switches flutter_tools to emit the native assets manifest instead of embedding in kernel, and a manual roll into g3 to switch emitting a manifest instead of embedding in kernel. A TODO is left in the code for those callbacks to be removed.
## Testing
Most of this PR cannot be tested in isolation. The code in this PR is heavily exercised in the follow up flutter_tools PR which creates the `NativeAssetsManifest.json` and removes the embedding of native assets in kernel files.
* This PR adds a unit test for parsing the JSON manifest.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The DlImageFilter code uses Skia geometry classes for its internal computations. This PR switches those implementations to use the Impeller geometry classes for consistency and 3rd party header file independence.
Split the channel messaging out of the system channels to make them
simpler to understand and refactor.
The new channel classes could be automatically generated in a second
phase, e.g. using Pigeon to reduce code usage.
The new classes don't have tests as they will already be covered by the
existing code.
This reverts commit 11123f1bbf8833d029f0800ca5830085347bcf95.
The implementation of the assert assumes that there is a single raster thread ID that will remain constant throughout the lifetime of the process. That is not true for scenarios like recreating the engine after suspending and resuming an Android app, or instantiating multiple engines within one process.
Locally this gives much better performance, about doubling frame time on the Pixel 4. This avoids multiple glbuffersubdata calls that seems to perform particularly bad on mobile devices.
Thinking about it more, I'm not sure that having a separate EncodeCommands API is useful for RenderPass/BlitPass. instead they should probably just use submit. but that is a refactor for another day.
https://github.com/flutter/flutter/issues/159177
In many embedder tests, we want to get at the appropriate backend-specific `EmbedderTestContext` subclass (`EmbedderTestContextGL`, etc.) in order to make backend-specific setup calls such as `SetGLFBOCallback()` or others. Formerly, this required casting the returned `EmbedderTestContext&` to the appropriate subclass in each test.
This templatises the `GetEmbedderContext()` method to return the appropriate backend-specific subclass directly.
Issue: https://github.com/flutter/flutter/issues/158998
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Extracts backend-specific code in DlSurfaceProvider to separate translation units. In particular, this allows for less conditional header includes, and more specifically, allows code relating to the Metal backend to include headers that include ARC-managed Objective-C types. Today we cast these all to void* (and manage refcounting manually) since these headers are included in dl_surface_provider.cc, which is a pure C++ translation unit.
No test changes since this patch includes no semantic changes.
Issue: https://github.com/flutter/flutter/issues/137801
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Moves all backend-specific renderer configuration out of `EmbedderConfigBuilder` and into the backend-specific subclasses of `EmbedderTestContext`. `EmbedderTestContext` is already backend-specific and as of recent patches, also houses compositor configuration, making it the natural home of this code.
As a result, we no longer need backend-specific methods such as `SetSoftwareRendererConfig`, `SetMetalRendererConfig`, `SetOpenGLRendererConfig`, `SetVulkanRendererConfig`. Nor do we need manual backend initialisation in `EmbedderConfigBuilder`. Nor does that initialisation any longer require relying on internal backend-specific code within `EmbedderTestContext`, since we now do that initialisation in the `EmbedderTestContext` constructor.
Since the bulk of the work previously done by this method now occurs in the `EmbedderTestContext` constructor, the only work remaining in these methods is surface creation. Further, since this is all now implemented in backend-specific `EmbedderTestContext` subclasses, they have all been renamed to a single method: `SetSurface`.
Previously, all of these methods took a surface_size parameter, with two exceptions:
* `SetVulkanRendererConfig` also took an optional `FlutterVulkanInstanceProcAddressCallback` parameter. This has been extracted to a separate method `SetVulkanInstanceProcAddressCallback` on `EmbedderTestContextVulkan`.
* `SetSoftwareRendererConfig` defaulted the parameter to a size of (1, 1). For consistency, this is no longer defaulted, and all call sites have been updated, consistent with other backends.
Lastly, one nice benefit is that because the render config is initialised in the `EmbedderTestContext` constructor, there's no longer a requirement to call `Set*RendererConfig` prior modifying any specific properties on the config, nor is it problematic to call the (replacement) `SetSurface` method after modifying the config. Where the renderer config was being customised in embedder unit tests, I've pushed that customisation up to the top of the test where the rest of the test context is configured.
This eliminates nearly all remaining `#ifdef SHELL_ENABLE_$BACKEND` blocks in the EmbedderTest infrastructure.
Issue: https://github.com/flutter/flutter/issues/158998
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Without this if a channel method call was in progress and then the
handler was destroyed the call could attempt to access the destroyed
handler. This is possible as the handler is recreated on engine restart.
However, in this case the result is not used so no invalid memory access
would occur. Adding the cancellable fixes any future change where this
would no longer be the case.
Also updates the image_filter_test.dart expected color values for a blur unit test. The legacy blur algorithm would a) treat very small blur sigmas as the identity even though the effect was still perceptible and b) was very inaccurate for sigmas < 2. The unit test used a sigma of 1.0 so fell within the inaccurate range but the expected values appear to have been taken directly from the original Skia output. This updates them to match the output of the new algorithm (which is also more consistent between CPU and GPU).
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Fixes https://github.com/flutter/flutter/issues/158963
If the GLES version is at least 3, then we can attach a sync fence to the texture gles object. If this operation succeeds, then we can use gl.Flush instad of gl.Finish. Then, when binding the texture - if a sync fence is present we wait and then remove the fence.
Update to the latest definitions of emulator configurations. (except x86/api28 see b/379736755)
Specifically to past https://crrev.com/c/5908894 which added `gpu_mode: "swangle_indirect"` to the api 35 proto. This should help with emulator stability on versions past android 13.
Related to b/371020223
Research notes / my findings for how this system works at go/flutter-android-ci-emulator
Eliminates the opt-out of `-Wunguarded-availability-new` in the `ios_test_flutter` target.
Xcode 15 beta XCTest framework headers contained unguarded usage of iOS 17 API. This bug resulted in engine build failures.
This was fixed in a later XCTest framework release.
```
/Applications/Xcode_15-beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Library/Frameworks/XCTest.framework/Headers/XCUIAccessibilityAuditTypes.h:19:30: error: 'XCUIAccessibilityAuditType' is only available on iOS 17.0 or newer [-Werror,-Wunguarded-availability-new]
19 | typedef NS_OPTIONS(uint64_t, XCUIAccessibilityAuditType) {
| ^
/Applications/Xcode_15-beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Library/Frameworks/XCTest.framework/Headers/XCUIAccessibilityAuditTypes.h:19:30: note: 'XCUIAccessibilityAuditType' has been marked as being introduced in iOS 17.0 here, but the deployment target is iOS 13.0.0
/Applications/Xcode_15-beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Library/Frameworks/XCTest.framework/Headers/XCUIAccessibilityAuditTypes.h:19:9: note: annotate anonymous enum with an availability attribute to silence this warning
19 | typedef NS_OPTIONS(uint64_t, XCUIAccessibilityAuditType) {
| ^
/Applications/Xcode_15-beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator17.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:383:34: note: expanded from macro 'NS_OPTIONS'
383 | #define NS_OPTIONS(_type, _name) CF_OPTIONS(_type, _name)
| ^
/Applications/Xcode_15-beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator17.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFAvailability.h:155:96: note: expanded from macro 'CF_OPTIONS'
155 | #define CF_OPTIONS(_type, _name) __attribute__((availability(swift,unavailable))) _type _name; enum __CF_OPTIONS_ATTRIBUTES : _name
|
```
Issue: https://github.com/flutter/flutter/issues/128958
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This addresses https://github.com/flutter/flutter/issues/159088
If the image is rotated in its exif data, the coded width/height may differ from the display width/height. It's important to use the display width/height so that `texImage2D` does the right thing with the `VideoFrame`.
For consistency with the Test.*Context classes for other backends, which live in their own implementation file with their own header, extract TestEGLContext to its own header and TU so that in cases where only a TestEGLContext is required (e.g. EmbedderTestBackingStoreProducerGL), we don't need to include all the various test GL surface classes as well.
GetEGLError is used by both TestEGLContext and the TestGLSurface classes, so moves to its own utils file.
No tests because this is a refactoring with no semantic changes, and the code itself is test code.
Issue: https://github.com/flutter/flutter/issues/158998
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Enables the `-fobjc-arc` compiler flag for Objective-C and Objective-C++
translation units.
Eliminates the flutter_cflags_objc[c]_arc settings, since they're now
redundant.
All Obj-C/Obj-C++ code in our codebase has now been migrated to ARC.
Issue: https://github.com/flutter/flutter/issues/137801
Replace the top-level public EmbedderBackingStoreProducer::UserData struct with backend-specific UserData classes, and make them internal to those backends. UserData internals shouldn't be visible to/manipulated by unit tests and compositors, but instead constrained to the backing store producer itself.
Issue: https://github.com/flutter/flutter/issues/158998
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
