This is part of a larger effort to expose the difference between GrDirectContext,
which runs on the GPU thread and can directly perform operations like uploading
textures, and GrRecordingContext, which can only queue up work to be delivered
to the GrDirectContext later.
* [fuchsia] fix Rasterizer::ScreenshotLayerTreeAsPicture on Fuchsia
* [fuchsia] Add shell test for skp based shader warmup
* [fuchsia] use custom image serialization when writing out SKP's
This change adds custom image serialization functions for skp serialization
which write out onlythe image metadata and not the contents of the
images themselves. This allows SKP's to be used for shader warmup with
a significantly reduced disk space footprint.
Tweak the primary flutter build rule so that fuchsia is more similar to
other platforms in how tests and the shell are built.
Only embedder_unittests and GLFW tests are disabled on Fuchsia now.
TEST: Ran unittests on host/fuchsia; workstation on fuchsia
BUG: fxb/53847, fxb/54056
Additionally create "_next" permutations for all of the test binaries
on Fuchsia, in order to test both code-paths.
Using the #define follow-up CLs can also create a flutter_runner_next
binary that does not contain any legacy integration code.
BUG: 53847
* Add PlatformView support for Fuchsia
This change allows embedding views provided by fuchsia components into
a flutter app running on Fuchsia. This conforms to Flutters idiomatic
approach to composite PlatformView alongside other rendered layers.
This uses the `view embedder` infrastructure to allow
`PlatformViewLayer`
to hold fuchsia views. This is meant to eventually supplant the legacy
`SceneHost` and `ChildViewLayer` mechanism to embed fuchsia `ChildView`.
To see how this will get used check out:
https://fuchsia-review.googlesource.com/c/experiences/+/398536/6/examples/hello_experiences/lib/fuchsia_view.dart
Includes unittests for platform_view.cc.
Note: This change has no impact on the legacy code to embed fuchsia
views.
* Rename OnCreateViewMethodCall to OnCreateView
Same for OnDestroyViewMethodCall to OnDestroyView
Co-authored-by: Sanjay Chouksey <sanjayc@google.com>
Adds a test that verifies that the view of the local time is the same in
the Dart isolate and the process that is running the test.
Specifically, this test is useful to verify that the code paths for
timezone retrieval do not break while the underlying FIDL protocols are
being refactored.
However, since the check is generally useful, the test is written as a
general flutter test.
Running this on Fuchsia required adding `fuchsia.intl.ProfileProvider`
to the CMX file that is used for all build Fuchsia packages.
Testing is a bit involved on Fuchsia. You must build the Fuchsia
package `fluter/shell/common:shell_tests` and publish it to the dev
repository for your Fuchsia device. It seems that a way to do so is to
modify the script `flutter/tools/fuchsia/build_fuchsia_artifacts.py` and
modify its function `GetTargetsToBuild` like so:
```
def GetTargetsToBuild(product=False):
targets_to_build = [
'flutter/shell/platform/fuchsia:fuchsia',
'flutter/shell/common:shell_tests',
]
return targets_to_build
```
Next, the Fuchsia packages need to be compiled and published.
Once done, the following `fx` invocation will run the test, assuming
that you have your Fuchsia setup:
```
fx shell run \
fuchsia-pkg://fuchsia.com/shell_tests#meta/shell_tests.cmx \
-- --gtest_filter=ShellTest.LocaltimesMatch
```
* Hook up PersistentCache to ShellTestPlatformViewVulkan
* [vulkan][fuchsia] enable vulkan without swiftshader in fuchsia tests on arm64
* [vulkan][fuchsia] Disable second half of ShellTest.CacheSkSLWorks on
vulkan backend
GrContext::precompileShader() is not implemented for vulkan contexts, so
dont run the portion of this test that depends on that behavior on
Vulkan.
Co-authored-by: George Wright <gw280@google.com>
The engine was using a global to store a timestamp representing the
launch of the engine. This timestamp is initialized with a JNI call
on Android and during shell setup on other platforms. Later the
timestamp is added to a FlutterEngineMainEnter timeline event used to
measure engine startup time in benchmarks.
This PR removes the global and the JNI call and moves the timestamp
into the settings object.
