* Revert "Add flow test fixtures and tests (#13986)"
This reverts commit 620f5281b819f304e8e9e945222e26b17b087cc3.
* Revert "Dynamically determine whether to use offscreen surface based on need (#13976)"
This reverts commit a86ef946563b020108320bbfb974bf7343284fd3.
This reverts commit f456423cfb820d07bb36e9a8979e3d75cc9d8d76.
This is being reverted because it caused flutter/flutter#45098
(images don't load on iOS).
This is a duplicate of flutter/engine#13360 with the test switched to use the software backend instead of the GL backend.
After some debugging and testing on another GL embedder I think the issue with the test is some bug having to do with the GL implementation in the test harness specifically.
Fixesflutter/flutter#38903
The earlier assumption was that the render target would be re-materialized per frame. The render target needs its own picture recorder to be create per frame as well. When render targets are cached in the registry, an existing target will be reused. But submitting the previous frame would have discarded the recorder already. The layer tree paint would then attempt to dererence a null canvas causing a crash at runtime.
Added tests to ensure that this does not happen both with and without a custom compositor specified by the embedder. I am going to rework this code so that the external view embedders thinks of render target access on a per frame basis but that is a larger change. This smaller patchset should unblock broken builds.
Fixes b/144093523
Previously the cache was disabled on whether or not PlatformViews were
globally enabled. Instead track their existence in the view hierarchy
and only disable RasterCache if a PlatformView is actually present.
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
This exposes platform_view_id on the embedder API's FlutterSemanticNode.
In bd0f9085e5bdbac74cc6e611f758768f15ad5415 (#8055), platformViewId was
added to SemanticsNode. This field is non-zero when the SemanticsNode
represents a platform view and is typically used by embedders as a means
of identifying locations where a platform view's 'native' accessibility
tree should be injected into the platform-specific accessibility tree
constructed by the embedder.
Due to the intended use of this field, the Flutter framework is meant to
enforce that this node has a child count of zero.
For embedder code that is configured for both AOT and JIT mode Dart execution
based on the Flutter engine being linked to, this runtime check may be used to
appropriately configure the `FlutterProjectArgs`. In JIT mode execution, the
kernel snapshots must be present in the Flutter assets directory specified in
the `FlutterProjectArgs`. For AOT execution, the fields `vm_snapshot_data`,
`vm_snapshot_instructions`, `isolate_snapshot_data` and
`isolate_snapshot_instructions` (along with their size fields) must be specified
in `FlutterProjectArgs`.
The contents rendered into the backing stores are already correctly scaled.
The initial implementation assumed this also held true for the metrics obtained
via embedded view parameters.
Fixes b/142699417
Embedders may use this to specify a thread whose event loop is managed by them
instead of the engine. In addition, specifying the same task runner for both
the platform and render task runners allows embedders to effectively perform
GPU rendering operations on the platform thread.
To affect this change, the following non breaking changes to the API have been
made:
* The `FlutterCustomTaskRunners` struct now has a new field `render_task_runner`
for the specification of a custom render task runner.
* The `FlutterTaskRunnerDescription` has a new field `identifier`. Embedders
must supply a unique identifier for each task runner they specify. In
addition, when describing multiple task runners that run their tasks on the
same thread, their identifiers must match.
* The embedder may need to process tasks during `FlutterEngineRun` and
`FlutterEngineShutdown`. However, the embedder doesn't have the Flutter engine
handle before `FlutterEngineRun` and is supposed to relinquish handle right
before `FlutterEngineShutdown`. Since the embedder needs the Flutter engine
handle to service tasks on other threads while these calls are underway,
there exist opportunities for deadlock. To work around this scenario, three
new calls have been added that allow more deliberate management of the Flutter
engine instance.
* `FlutterEngineRun` can be replaced with `FlutterEngineInitialize` and
`FlutterEngineRunInitialized`. The embedder can obtain a handle to the
engine after the first call but the engine will not post any tasks to custom
task runners specified by the embedder till the
`FlutterEngineRunInitialized` call. Embedders can guard the Flutter engine
handle behind a mutex for safe task runner interop.
* `FlutterEngineShutdown` can be preceded by the `FlutterEngineDeinitialize`
call. After this call the Flutter engine will no longer post tasks onto
embedder managed task runners. It is still embedder responsibility to
collect the Flutter engine handle via `FlutterEngineShutdown`.
* To maintain backwards compatibility with the old APIs, `FlutterEngineRun` is
now just a convenience for `FlutterEngineInitialize` and
`FlutterEngineRunInitilaized`. `FlutterEngineShutdown` now implicitly calls
`FlutterEngineDeinitialize` as well. This allows existing users who don't care
are custom task runner interop to keep using the old APIs.
* Adds complete test coverage for both old and new paths.
Fixes https://github.com/flutter/flutter/issues/42460
Prerequisite for https://github.com/flutter/flutter/issues/17579
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.
See b/141980393 for details.
In the issue, the embedder (assumed to render Flutter contents of size 800 x 600 [1]) is meant to be displayed on its side. To achieve this, it specifies a root surface transformation that translates the surface by its width (or height when it held in the correct viewing position) and then rotates it counter-clockwise by 90 degrees. This test verifies that the Flutter Engine accounts for those transformations in the custom compositor platform view coodinates.
[1] The actual size is something different. 800x600 is for illustrative purposes.
