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
Also creates a new test harness for the desktop embedder framework target and adds a test that launches a headless engine in this new thread configuration.
Fixes https://github.com/flutter/flutter/issues/17579
This exposes platform_view_id on the embedder API's FlutterSemanticNode.
In 40e0467f60dd2174af5b3edf8bd2752eb6251bf1 (#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.
The FIDL service `fuchsia.intl.PropertyProvider` is a service that
the flutter runner can use to obtain information on system preferred
locales.
This change sends a platform message "setLocale" on the channel
"flutter/localization", based on the values provided by the above
mentioned FIDL service.
Credit: most of this was initially written by @kpozin; I ported it
to out-of-tree flutter engine.
Tested:
1. Compile and publish the unit tests package as shown in
the script below.
2. In a Fuchsia repository (pointed to by `$FUCHSIA_DIR`), run
`fx serve`
3. `fx shell run fuchsia-pkg://fuchsia.com/flutter_runner_tests#meta/flutter_runner_tests.cmx`
The script used to update the unit tests.
```bash
set -x
FLUTTER_ENGINE_DIR="${FLUTTER_ENGINE_DIR:-$HOME/fx/flutter/engine/src}"
readonly OUT_DIR="${FLUTTER_ENGINE_DIR}/out"
(
cd ${FLUTTER_ENGINE_DIR}
./flutter/tools/gn --fuchsia --fuchsia-cpu x64 --unoptimized
ninja -j 100 -C "${OUT_DIR}/fuchsia_debug_unopt_x64"
cp "${OUT_DIR}/compile_commands.json" "${FLUTTER_ENGINE_DIR}"
echo "Publishing the tests package"
"${FLUTTER_ENGINE_DIR}/fuchsia/sdk/linux/tools/pm" publish \
-a -r $FUCHSIA_DIR/out/release/amber-files \
-f "${FLUTTER_ENGINE_DIR}/out/fuchsia_debug_unopt_x64/flutter_runner_tests-0.far"
)
```
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 view was being accessed from a background thread so its OpenGL context could be accessed. This tripped thread safety assertions in Cocoa. Now the OpenGL context is stashed in the FlutterEngine instance itself.
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.
Remove dead shared snapshot arguments to Dart_CreateIsolateGroup.
6a65ea9cad4b [vm] Remove shared snapshot and reused instructions features.
db8370e36147 [gardening] Fix frontend-server dartdevc windows test.
4601bd7bffea Modified supertype check error message to be more descriptive.
0449905e2de6 [CFE] Add a serialization-and-unserialization step to strong test
c8b903c2f94f Update CHANGELOG.md
2a12a13d9684 [Test] Skips emit_aot_size_info_flag_test on crossword.
b26127fe01a5 [cfe] Add reachability test skeleton
Obtaining the SkiaUnrefQueue through the IOManager is unsafe because
UIDartState has a weak pointer to the IOManager that can not be dereferenced
on the UI thread.
This is part of an effort to separate generation of
host artifacts and target artifacts for fuchsia. The
`fuchsia_host_bundle` template aims to capture all the
artifacts that are specific to a given host.
The next step would be to bundle these are separate CIPD
packages for mac and linux (only x64 hosts)
internal planning doc: go/flutter-fuchsia-packaging
Adds repeatCount field to KeyEventChannel.FlutterKeyEvent. We set it
to the value returned by KeyEvent.getRepeatCount() and add it to the
message passed through the channel with the intention of exposing it
in RawKeyEventDataAndroid on the framework side.
flutter/flutter#42855
This re-enables thread safety checks for WeakPtr. WeakPtrs can't be used on a thread other than the one the WeakPtrFactory was created on.
This fixes the unit tests and adds a getUnsafe() method to WeakPtr to work around the remaining unresolved locations where we are using WeakPtr unsafely.
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
Adds a task runner, and exposes API to allow application-level runloops to know when they need to next call the API to process engine events. Internally, sends null events to wake up the app runloop when new events are scheduled to ensure the wait time is updated accordingly.
Fixes#36420
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
