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.
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
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
In https://github.com/flutter/engine/pull/53280, I'm adding
lifecycle-aware methods to `SurfaceProducer`.
That means, in order to test that it WAI, we'll need to be running in a
simulated activity, and be able to switch scenario states (i.e. to
`RESUMED`). This was mentioned as well in
https://github.com/flutter/flutter/issues/133151 as being something we
want to do.
This PR adds a `FlutterEngineRule`, which allows the creation of a
"real" `FlutterEngine` and an `Intent` that can power
`AndroidScenarioRule<FlutterActivity>`. I felt bad doing all of this
work for a single `@Test`, so I also refactored the rest of the file and
cleaned things up a bit.
That said, I'm happy to revert or make changes if we liked how things
were setup before.
Reverts flutter/engine#53136
b/345642546 shows some massive performance regressions on this patch. i'll rework it so the conditions are only loosened on phones with one fast core.
For devices with 1 fast core, the current affinity set is less idea because it forces UI and raster on the same thread. Widen this to exclude slow cores instead of including only the fast core.
Reverts: flutter/engine#53099
Initiated by: jonahwilliams
Reason for reverting: manifest opt out doens't work.
Original PR Author: jonahwilliams
Reviewed By: {bdero, zanderso, chinmaygarde}
This change reverts the following previous change:
All plugin migrations have landed. Enable impeller by default on Android.
Reverts: flutter/engine#53108
Initiated by: jonahwilliams
Reason for reverting: Probably --no-enable-impeller isn't working
Original PR Author: jiahaog
Reviewed By: {jonahwilliams}
This change reverts the following previous change:
After https://github.com/flutter/engine/pull/53099, impeller is always enabled, even if the manifest disables it using `io.flutter.embedding.android.EnableImpeller`.
This PR causes it to respect the manifest value if it is explicitly disabled.
Fixes b/343603270
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Add `SemanticsAction.focus`. This PR just adds the new enum value without any logic. Adding the enum value first to unblock work that needs to be done on both the engine and framework side that will actually implement all the necessary logic.
This is PR 1 out of ~3 for https://github.com/flutter/flutter/issues/83809
Revert label failed due to conflicts
`FlutterFragmentTest.java` was the only file that had merge issues, everything else is the output of `git revert 802e5d2cd3c9e73f336e3fe43487b64a5fdf98d8`
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Android add-to-app apps now support predictive back when going between Activities or back to the home screen. Predictive back route transitions within the Flutter part of the app are not yet supported.
Upgrades every `androidx` dependency in the `src/third_party/android_embedding_dependencies` bundle to the latest version, except the `lifecycle` group*. Tested running a couple of apps as well because when updating these dependencies in the past I've been able to build the engine but then flutter run fail when trying to run an app.
Fixes https://github.com/flutter/flutter/issues/129307, also unblocks a feature that will eventually be needed for Scribe.
[*]`2.8.0` is the latest there, but I ran into an issue with dexing when I tried to upgrade, due to b/336164417, an AGP bug that had its fix backported to all >`8.0.0` versions, but we still support less than that so we will have to wait on that upgrade.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
When you background an activity via the back-gesture the onTrimMemory callback is not invoked but the buggy Android behaviour still occurs.
Workaround this by faking an onTrimMemory callback in the `Activity#onStop` callback.
Fixes#148662
Related #146499
Tested manually on a Pixel 7 Pro running Android 14.
Work towards https://github.com/flutter/flutter/issues/139702.
I think we should also `@Deprecate`/cleanup the API surface in
`FlutterView`, but that needs a bit more a discussion.
/cc @johnmccutchan
This wires up Android Hardware Buffer backed swapchains on platform that support
it (Android >= 29) with a KHR swapchain fallback (which can be removed later to
save on some binary size if needed).
Some salient features of these swapchains and their differences with the KHR
variant:
* All swapchain images are guaranteed to R8G8B8A8. This could potentially allow
for earlier creation of the context and the PSO libraries.
* All swapchain allocations are lazy. This should greatly reduce the time it
takes to create and resize a swapchain. However, swapchain image acquisition
may take longer for the first few frame where there is no pre-pooled image
available. Resizes should be similarly faster since the swapchain images for
the intermediate sizes are never created.
* Swapchain transients allocations (the attachments for the root render target)
are also lazily allocated.
* Swapchain images are pool and reused. The size of the pool is user specified
(currently 2). If an image in the pool ages past a user supplied value
(currently 1 second), it is collected as well. Applications that don't render
frames for a long period of time should see less memory use because of
swapchain image allocations.
* The present mode of AHB swapchains behave similar to KHR swapchains but with
VK_PRESENT_MODE_MAILBOX_KHR. In cases where there is no application managed
frame pipelining, this might cause images to never be presented if a newer
image is available. This wasted work can only be avoided by application
provided pipelining.
* There are no client side waits during image presentation. Instead, a new type
of fence is wired up that exports its state as a sync file descriptor. The
fence signal operation is enqueued on the client side and the buffer is set on
the surface control. The presentation engine then performs the wait.
* On Qualcomm devices, Chromium seems to be setting vendor specified flags for
opting the hardware buffers into using UBWC. AFAICT, this is similar to AFBC
(and NOT AFRC) on ARM Mali. This has not been wired up since I don't have a
Qualcomm device at the moment and cant verify bandwidth use using GPU
counters. I would also like to verify that UBWC is safe to use to images that
can be used as input attachments.
I suspect that the change to clear the surface is the result of the
scenario app instability. just a guess: the screenshots looks like we're
missing the platform view. maybe the clearing of the surface is causing
an extra frame to be pushed. That frame is getting picked up in the
golden due to a race condition that is hard to hit locally
Testing disabling of this functionality in the golden test. If this pass
a real fix involves some sort of hook into the rendering to verify it
has fully completed before screenshotting.
Without this, an opaque black surface may briefly flash onscreen when the platform view is shown (see internal issue b/332379081)
This matches the behavior used before to the introduction of PlatformViewRenderTarget in b3945f7706
That commit moved the clearing of the surface into SurfaceTexturePlatformViewRenderTarget. But that caused surface clearing to happen in scenarios where there was no PlatformViewWrapper, resulting in the issue seen in https://github.com/flutter/flutter/issues/141068
Later the surface clearing was removed from SurfaceTexturePlatformViewRenderTarget, causing the flashing black screen.
Reverts: flutter/engine#51229
Initiated by: gmackall
Reason for reverting: blocking engine->framework roll (I missed some framework code referencing the v1 embedding).
Original PR Author: gmackall
Reviewed By: {matanlurey, reidbaker}
This change reverts the following previous change:
Fixes https://github.com/flutter/flutter/issues/143531
Also fixes a random typo I found
~TODO to test this~ (no more todo):
-~test the framework against this as well, probably with a dummy PR changing the engine commit to my branch if this is possible~ not possible, made a best effort removal of framework code in https://github.com/flutter/flutter/pull/144726.
-~figure out if the old embedding is used in g3 at all~ removed all uses
-~figure out exactly what the ShimPluginRegistry/ShimRegistrar are doing, and if fully deleting them was right~ (see https://github.com/flutter/engine/pull/51229#issuecomment-1981757743)
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Finishes part 2 of https://github.com/flutter/flutter/issues/145263.
This required fixing a python script to use the version of Java obtained
through the DEPS file rather than one assumed to exist in the
environment.
