The FlutterComputePlatformResolvedLocaleCallback does not pass the
standard user_data baton. This was an unintentional omission in the
original patch.
Add documentation to that effect and link to the bug report:
https://github.com/flutter/flutter/issues/79826
FlutterDesktopEngineCreate is part of our C API. We were using a C++
reference type instead of a C-compatible pointer type.
This is a breaking change to anyone calling this directly; we believe
this should affect few people because the Windows template only uses the
`FlutterEngine` wrapper in
`shell/platform/windows/client_wrapper/include/flutter/flutter_engine.h`.
Fixes https://github.com/flutter/flutter/issues/75465
Embedders making use of the embedder API always ended up with a
hardcoded log tag of "flutter". Some embedders may wish to set a
different log tag. For example, the Fuchsia embedder sets their log tag
to a launch URL followed by "flutter".
If unset, we continue to default to "flutter".
Fixes https://github.com/flutter/flutter/issues/79819
Previously messages logged from Dart code (e.g. via the print function)
were handled directly in the engine by platform-specific code. This
factors out a LogMessage(tag, message) callback that embedders can
implement with platform-specific code.
This also eliminates a dependency on platform-specific code in the core,
and provides more flexibility to embedders than the current fallback to
stdout, which can be a problem on platforms without a traditional stdout
or with restrictions on stdout.
Fixes https://github.com/flutter/flutter/issues/79685
Notify Skia that we've updated texture handles within the current
binding such that Skia invalidates any assumptions about previous
context modifications that it had made.
This fixes a texture corruption issue reported in
https://github.com/flutter/flutter/issues/78648
* [fuchsia][shader warmup] Fixed SkpWarmupTest
This test regressed due to https://github.com/flutter/engine/pull/23488
and this regression was silent due to https://github.com/flutter/flutter/issues/78277
Credit to @gnoliyil for actually putting together the fix.
* [fuchsia][shader warmup] Avoid recursively iterating over assets directory when loading skp's due to high cost of openat() on pkgfs
Used the the `misspell` tool available at
https://github.com/client9/misspell, then applied hand-corrections. It's
possible we could adopt this as a presubmit, but there are still enough
false positives that it may not be worth the effort.
Per https://fuchsia.dev/fuchsia-src/concepts/testing/v1_test_component,
in order to access non-basic system services like Vulkan loader and
sysmem allocator, we need to add "system-services" field to the cmx
metadata file.
Unittests like "shell_test" requires Vulkan to run properly, so we
add Vulkan loader and sysmem services; for Flutter runner tests,
we also need to add fuchsia.ui.scenic.Scenic since the test needs
to create a Scenic session as well.
TEST=shell_tests (SkpWarmupTest.Basic/SkpWarmupTest.Image)
flutter_runner_tests (EngineTest.SkpWarmUp) on FEMU
This will cause the previous texture binding used by Skia to be
incorrectly unbound, such that should they need to re-used an existing
binding, we'll end up rendering blank instead.
Instead we should be using
context->flushAndSubmit();
context->resetContext(kAll_GrBackendState);
in `EmbedderExternalTextureGL::ResolveTexture` in order to notify Skia
that we've updated handles within the current binding and invalidate any
assumptions about previous modifications it has made to the context.
This reverts commit eff2763bd561ef9ca6d7834f785013d20e525d60.
Chrome Trace viewer treats events labeled "VSYNC" as special and highlights them (when the "Highlight Vsync" checkbox is enabled). Ideally VSYNC events are generated by the host system at their source. System VSYNC events are indeed present in full-system systraces. Flutter-level traces (as seen in Observatory/Flutter devtools) do not contain the system VSYNC events, so we rely on the engine to generate them (as close to where they would be generated by the system ideally).
Flutter crash reports on Fuchsia are considered non-fatal because they're not filed in response to the termination of the Flutter application, just a Dart exception that was thrown.
