This addresses the problem in https://github.com/flutter/flutter/issues/12847 which changed slightly over time.
Today, `Platform.script` does not give an empty `file` URI, it gives something like `file://path/to/package/main.dart` _regardless of how the file is actually named_.
After this change, it will give the absolute path to the file being run under test.
So before this change, the new test would have a URI like
```
file:///Users/dnfield/src/flutter/engine/src/main.dart
```
And now it has
```
file:///Users/dnfield/src/flutter/engine/src/out/host_debug_unopt_arm64/gen/platform_test.dart.dill
```
This is going to be helpful in generating relative paths from the test file.
*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
- Refactor the fence waiting code to only wait on Android >= 33.
- Log a warning message once per image rendering target on Android >= 29 && < 33.
- Add a simple unit test of ImageReaderPlatformViewRenderTargets.
The Impeller ContextVK contains a ConcurrentMessageLoop whose threads may invoke Dart timeline APIs. The Dart APIs will create a thread-local object that will be deleted during thread shutdown. Therefore, these threads should not outlive the engine/Shell and Dart VM.
Previously, RunTester held the ImpellerVulkanContextHolder on the stack, and its reference to the ContextVK would be dropped while exiting the function after the Shell is destructed.
This PR moves the contents of the tester's ImpellerVulkanContextHolder out of the instance on the stack and into a lambda owned by the Shell.
It also reenables the flutter_tester Impeller tests in the run_tests script.
Follows up on #46389
That patch was too permissive in cases where a build system enables impeller but not vulkan. This change makes the build succeed in such systems.
When objcopy is used to embed data into a linkable object file, that
object file will only have default bits set in its header for ABI etc..
If the linker doesn't cooperate by ignoring ABI mismatches on object
files without code, then linking will fail. This PR stops using objcopy
to create an object file that embeds icudtl.dat into the Android
embedder, and instead uses the `bin_to_assembly.py` script that we're
already using for Dart VM snapshot data.
Context in https://github.com/llvm/llvm-project/issues/68915
This patch does the following:
- Updates `flutter_tester` to set up an Impeller rendering context and surface if `--enable-impeller` is set to true, using the Vulkan backend with Swiftshader.
- Updates `run_tests.py` to run all tests except the smoke test (that one really has no rendering impact whatsoever) with and without `--enable-impeller`.
- Updates a few tests to work that were trivial:
- A couple tests needed updated goldens for very minor rendering differences. Filed https://github.com/flutter/flutter/issues/135684 to track using Skia gold for this instead.
- Disabled SKP screenshotting if Impeller is enabled, and updated the test checking that to verify an error is thrown if an SKP is requested.
- The Dart GPU based test now asserts that the gpu context is available if Impeller is enabled, and does not deadlock if run in a single threaded mode.
- We were missing some trace events around `Canvas::SaveLayer` for Impeller as compared to Skia.
- A couple other tests had strict checks about exception messages that are slightly different between Skia and Impeller.
- I've filed bugs for other tests that may require a little more work, and skipped them for now. For FragmentProgram on Vulkan I reused an existing bug.
This is part of my attempt to address https://github.com/flutter/flutter/issues/135693, although @chinmaygarde and I had slightly different ideas about how to do this.
The goals here are:
- Run the Dart unit tests we already have with Impeller enabled.
- Enable running more of the framework tests (including gold tests) with Impeller enabled.
- Run all of these tests via public `dart:ui` API rather than mucking around in C++ internals in the engine.
Fixes internal bug b/303652511 and includes a regression test.
The TL;DR of the bug is that when re-launching a singleton-cached-engine
Flutter activity using FLAG_ACTIVITY_CLEAR_TASK, the teardown of the
previous Flutter activity interleaves with the creation of the new
Flutter activity, resulting in the Flutter engine ending up incorrectly
in the AppLifecycleState.detached state. This then results in the app
being completely unresponsive because Flutter doesn't draw frames in
this state. I don't know if the issue is reproducible in production
under normal user operation, but I'm concerned it very easily could be.
There's also nothing stopping other apps or Android system code from
launching an app using this flag.
## Description
This Android related PR adds a channel buffer and a plugin to interact with Android 'process text' feature. It makes it possible to query text processing actions and to run those actions (for instance 'calling' Google translate).
Text actions that outputs a processed text are supported.
The implementation is based on the great sample provided by @gualse , see https://github.com/flutter/flutter/issues/107603#issuecomment-1646629158.
In order to return a non empty list of text actions, the implementation will require adding a section to the Android manifest file (see https://github.com/flutter/flutter/issues/107603#issuecomment-1683487087).
Adding this section automatically to new or existing Flutter apps is not part of this PR but will be tackled in a future PR.
## Related Issue
Android engine side for https://github.com/flutter/flutter/issues/107603
## Tests
Adds 3 tests.
As part of eliminating the Flutter buildroot (#67373), we are moving all
third-party dependencies from //third_party to //flutter/third_party.
This is the engine-side follow-up to flutter/buildroot#777.
Once all third-party dependencies have been migrated, tooling and config
will be moved and the buildroot will be eliminated altogether.
Issue: https://github.com/flutter/flutter/issues/136284
No tests changed because there is no semantic change to this PR. This is
simply relocating a dependency.
The root bug (b/300627634) was that we were holding onto HardwareBuffers
after the owning Image was closed. This CL refactors the C++ code to
properly hold a reference to the Image until it is safe to dispose of.
This CL also refactors the Impeller GL and Skia GL code paths to share
more code.
The PlatformView does not have a semantics container when added to semantics tree, this PR gives it a semantics container to ensure accessibility traversal works.
This fixes https://github.com/flutter/flutter/issues/135504, which is a regression of 738b1ad94d
Before 738b1ad94d, the traversal works because the PlatformView is added to the accessibilityElements of the FlutterPlatFormViewSemanticsContainer, which implicitly made the FlutterPlatFormViewSemanticsContainer as the PlatformVIew's AccessibilityContainer.
Now we use the PlatformVIew as the nativeAccessibility of the FlutterPlatFormViewSemanticsContainer, we need to expilicitly set the container.
This needs to be cherry-picked since the commit caused the regression was cherry-picked in 738b1ad94d
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
An internal customer is seeing flickering on some high FPS phones.
While we try and reproduce / gain more knowledge of this problem this PR adds a AndroidManifest.xml flag to disable their usage.
The boolean flag is:
```
"io.flutter.embedding.android.DisableImageReaderPlatformViews"
```
Adding the following to your manifest will disable their usage:
```
<meta-data
android:name="io.flutter.embedding.android.DisableImageReaderPlatformViews"
android:value="true" />
```
This PR refactors `Rasterizer` so that it's more suitable for multi-view.
Design doc: [flutter.dev/go/multi-view-pipeline-and-rasterizer](http://flutter.dev/go/multi-view-pipeline-and-rasterizer)
With this change, `Rasterizer::DrawToSurfaces` has a structure that can handle drawing to multiple views, although the lack of some functionality still blocks it, mostly related to `ExternalViewEmbedder` and `RasterCache`.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Fixes the issue in original PR where `FlutterViewWrapper` does not pass the key equivalent to subviews thus prevents `TextInputPlugin` from receiving it. Also adds a regression test for this scenario.
Note that key equivalent flow does not respect the regular responder chain. It is passed from root view to down to subviews and if unhandled will be forwarded to menus.
Original message:
https://github.com/flutter/engine/pull/40706 added a duplicate `NSEvent (KeyEquivalentMarker)` category. This PR removes it. It also removes the call to `markAsKeyEquivalent` from `FlutterViewController`. That call is internal to `FlutterTextInputPlugin` and classes outside should not be calling it.
*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
Fixes https://github.com/flutter/flutter/issues/134699
Because of NSTextInputContext API limitations it is not straightforward to determine whether `TextInputPlugin` has handled a text equivalent event or whether it should pass it on. Previously we marked all event that didn't result in a TextInputClient action as unhandled, but that's does not work for arrow key events while the IME popover is active.
This PR will mark arrow keys event as handled if there is active composition.
*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
On Linux setting the EGL context from one thread, then setting from another thread will trigger a EGL_BAD_ACCESS error. The resolution is to clear the context after use on the thread that set it.
https://github.com/flutter/flutter/issues/130619
# Description
This PR fixes the `gl_populate_existing_damage` in embedder.cc, which currently returns an empty rectangle when a full repaint is needed. This leads to the `frame_damage` being considered empty in rasterizer.cc, causing incorrect partial repaint within Flutter when `gl_populate_existing_damage` is not provided by the embedder.
# Related Issue
https://github.com/flutter/flutter/issues/119601
# Tests
Add a new test. Also fixes damage calculation related tests in EmbedderTest by
* Use a new Dart embedder fixture entry point `render_gradient_retained` which retains the old layer to make sure layer tree diff happens.
* Add `latch.Wait()` after `SetGLPresentCallback` to make sure assertions have been executed.
* Make `existing_damage_rects` static since it should be valid after `populate_existing_damage` returns.
This relands https://github.com/flutter/engine/pull/45310 to unblock the ANGLE roll with the fix for https://github.com/flutter/flutter/issues/134262.
## Background
### Swap interval
If the Windows system compositor is enabled, the Windows embedder disables the swap interval so that presenting to a surface does not block until the v-blank. If the Windows system compositor is disabled (which is possible on Windows 7), the Windows embedder enables swap interval to prevent screen tearing.
### GL context threading
Our current version of ANGLE allows making a GL context current on multiple threads. However, the latest version of ANGLE errors if a GL context is made current on multiple threads. This is causing the ANGLE roll to fail ([example](https://ci.chromium.org/ui/p/flutter/builders/try/Windows%20Engine%20Drone/203788/overview)).
The Windows embedder has two GL context threading issues:
1. At startup, the platform thread creates and binds the GL context. This change ensures the GL context is released from the platform thread so that the raster thread can use the GL context for rendering.
2. When the system compositor updates, the GL context is bound to the platform thread to update the swap interval. This change ensures the swap interval update happens on the raster thread.
### Window resizing
Resizing the window recreates the GL surface and resets the swap interval.
The previous fix released the current GL context after updating the swap interval (this ensured the platform thread released the GL context at startup). This broke window resizing as it caused the engine to "lose" its GL context during rendering (see https://github.com/flutter/flutter/issues/134262). This reland releases the GL context only if on the startup case.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
