When gr context is changed (this happens when sending the app to the background and then to the foreground) we need to update it for all the platform view overlay surfaces.
The update logic was caching the previous gr context to figure if it had to be updated, but after updating it for a given overlay we were updating the cached context. In apps with multiple platform views this will result in overlays with a stale gr context.
This fixesflutter/flutter#36437
And I believe it should fixflutter/flutter#36999 as well (though I don't have repro code to verify).
Having 2 or more platform views simultaneously in the layer tree was crashing immediately on iOS with GL backend.
This regressed in #11070 which passed gl_context to a function in a loop using std::move (which meant on the second iteration the caller is no longer the owner of the field).
I added a scenarios_app test, though this test doesn't run on a physical device on CI so it would have only caught the problem when running locally (flutter/flutter#43852).
Make flutter_tester support multithreaded testing, and run all Dart tests in both single and multithreaded configurations
This also modifies Shell::GetUIIsolateLastError() and Shell::EngineHasLivePorts() so that they must be called from the UI task runner.
SkiaUnrefQueue should be empty at destruction time. If the queue is nonempty,
then there will be a pending drain task that will hold a reference to the
queue. The queue can only be destructed after the drain completes and the
reference is dropped.
Drains must only be done on the queue's task runner thread, which may not be
the thread where the queue is destructed.
Started asserting the FlutterEngine is running before communicating
over channels. This changes a null pointer exception to an
NSException that will provide some meaningful data to clients
incorrectly using the engine in an add-to-app situations.
The earlier design speculated that embedders could affect the same
transformations on the layers post engine compositor presentation but before
final composition.
However, the linked issue points out that this design is not suitable for use
with hardware overlay planes. When rendering to the same, to affect the
transformation before composition, embedders would have to render to an
off-screen render target and then apply the transformation before presentation.
This patch negates the need for that off-screen render pass.
To be clear, the previous architecture is still fully viable. Embedders still
have full control over layer transformations before composition. This is an
optimization for the hardware overlay planes use-case.
Fixes b/139758641
The tests we write must be resilient to the order in which they are run in the
harness. That is, they must not rely on global state set by other tests that
have already run in the process. Also, these tests must themselves be
repeatable. That is, they must correctly clean up after themselves and be able
to run successfully again in the same process.
This patch adds some safeguards against (but does NOT guarantee) the addition of
tests that violate the dictum.
Additionally, test failures must be easily reproducible for folks investigating
the test failure. Also, tests that assert correctness of unrelated code must not
stop progress on the authors patch.
This changes does not hinder reproducibility of test failures because the random
seed is printed in the logs before running each test. Developers attempting to
reproduce the failure locally can do the same via the following invocation
`--gtest_shuffle --gtest_repeat=<the count> --gtest_random_seed=<seed from failing run>`.
This change does introduce potential burden on patch authors that may see
failures in unrelated code as a newly failing shuffle seed is used on their
runs. To ameliorate this, we will formulate guidance for them to aggressively
mark such tests as disabled and file bugs to enable the same.
The test seed is intentionally kept low because it’s purpose is to test that
individual tests are repeatable. It must not be used as a replacement for
fuzzing.
