Some embedders use a custom platform task runner that does not support fml::MessageLoopTaskQueues and may not have an fml::MessageLoop.
To support those embedders, DartIsolate::SetMessageHandlingTaskRunner will not use fml::MessageLoopTaskQueues for platform isolates.
See https://github.com/flutter/engine/pull/48551#issuecomment-1962190896
Previously the DisplayListBuilder would only pass along bounds for a saveLayer when they were supplied by the caller that was building the DisplayList. This would require Impeller to use post-processing of the EntityPass lists to compute them on its own.
DisplayList can now compute those bounds as it builds the DisplayList to save dispatch clients from having to do so on their own. It will also provide an indicator in the case when the caller supplied bounds that ended up being too small to capture all of the content, causing clipping by the layer render target.
The GPUSurfaceGLImpeller ctor creates an AiksContext/ContentContext, which loads the shader pipelines. If the current thread does not have a GL context and can not execute ReactorGLES operations, then the pipeline futures will not complete. This can cause the raster thread to hang if the reactor has not run and the futures are still incomplete when a rendering task later needs to obtain the pipeline.
Without this, the EmbedderExternalViewEmbedder's call to SurfaceFrame::Submit will render an empty display list that will overwrite the output rendered by the external view embedder's layers.
See https://github.com/flutter/flutter/issues/143387
This PR adds `String? identifier` to `SemanticsUpdateBuilder` (currently it's only available in the temproary `SemanticsUpdateBuilderNew` API.
This is mainly targeted at https://github.com/flutter/flutter/issues/17988
Steps:
part 1: [engine] add `SemanticsUpdateBuilderNew` https://github.com/flutter/engine/pull/47961
part 2: [flutter] use `SemanticsUpdateBuilderNew` https://github.com/flutter/flutter/pull/138331
**part 3: [engine] update `SemanticsUpdateBuilder` to be the same as `SemanticsUpdateBuilderNew`** <-- we are here
part 4: [flutter] use (now updated) `SemanticsUpdateBuilder` again.
part 5: [engine] remove `SemanticsBuilderNew`
## Description
Before we deprecate the `RawKeyEvent` code, it needs to provide parity in functionality. One thing that is missing is the `eventSource` field from the `RawKeyEventDataAndroid` class, which provides the device type for the event.
See https://developer.android.com/reference/android/view/InputDevice#SOURCE_KEYBOARD for an example.
This PR implements that support, and sets the source to `KeyEventDeviceType.keyboard` for platforms that don't provide this information. The main thing it does is add the enum `KeyEventDeviceType`, and a new field `KeyData.deviceType`.
## Related Issues
- https://github.com/flutter/flutter/issues/136419
## Tests
- Updated tests to also read/write/verify this property.
# Description
This PR fixes the `gl_populate_existing_damage` in embedder.cc, which currently returns an empty rectangle when a full repaint is needed. This leads to the `frame_damage` being considered empty in rasterizer.cc, causing incorrect partial repaint within Flutter when `gl_populate_existing_damage` is not provided by the embedder.
# Related Issue
https://github.com/flutter/flutter/issues/119601
# Tests
Add a new test. Also fixes damage calculation related tests in EmbedderTest by
* Use a new Dart embedder fixture entry point `render_gradient_retained` which retains the old layer to make sure layer tree diff happens.
* Add `latch.Wait()` after `SetGLPresentCallback` to make sure assertions have been executed.
* Make `existing_damage_rects` static since it should be valid after `populate_existing_damage` returns.
Update: Blocked on https://github.com/flutter/engine/pull/44912 landing,
and merging into google3.
---
Partial work towards https://github.com/flutter/flutter/issues/112498.
_**tl;dr**: In Impeller's backend we intend to _always_ dither
gradients, and never allow any changes long-term (i.e., write your own
shader if you want different behavior) with the assumption that dithered
gradients look better most of the time, and don't typically hurt
elsewhere._
Note that, at the time of this writing, I couldn't find a single case of
this being set explicitly to `true` inside Google, and there are between
[100 and 200 publicly accessible on
GitHub](https://github.com/search?q=%22Paint.enableDithering%22+language%3ADart&type=code&l=Dart),
of which virtually all are setting it explicitly to `true`.
There are some (valid) concerns this would cause a lot of golden-file
image diffs, so I'm going to seek explicit approval from the Google
testing team as well as someone from the framework team before landing
this commit.
This introduces `PlatformDispatcher.implicitView`, a low-level primitive for the framework's bootstrapping. Most code, including the framework after bootstrapping, will use `View.of(context)` instead of this new API. This new primitive will let us deprecate the `window` global.
Goals:
1. **Enable multi-window**. The `PlatformDispatcher.implicitView` is nullable. If `null`, the app must create a window to get a view it can draw into.
2. **Backwards compatibility**. For "single window" apps, `PlatformDispatcher.instance.implicitView` should behave as similar to `window` as possible.
1. The `PlatformDispatcher.instance.implicitView.viewId` should be `0`.
1. The `PlatformDispatcher.instance.implicitView` must be available synchronously at root isolate startup. This allows the framework to determine if it can make single window assumptions at startup.
2. The `PlatformDispatcher.instance.implicitView` reference must not change after startup: if it is null at startup, it must always be null; if it is non-null at startup, it must always be non-null. If "single window" app enters headless mode, the implicit view must remain non-null.
In the future, the embedder will control whether an implicit view is created: mobile & legacy desktop apps will have an implicit view, multi-window desktop apps won't have an implicit view. This requires updating the engine's embedder API and is out-of-scope for this change. For now, all apps will have an implicit view.
Part of https://github.com/flutter/flutter/issues/120306
This ensures FlutterMetalTexture.destruction_callback gets called.
FlutterRendererConfig.get_next_drawable_callback holds a callback used by the embedder API to request a drawable; in the case of Metal, this drawable is a FlutterMetalTexture.
FlutterMetalTexture.destruction_callback should be called when it's safe to release resources associated with the FlutterMetalTexture. This callback is not currently invoked for textures returned via FlutterRendererConfig.get_next_drawable_callback; instead we unpack the returned struct and pass it on.
In the compositor codepath, we do create an SkSurface that triggers the destruction callback, here:
bbdb5d6a3e/shell/platform/embedder/embedder.cc (L868-L881)
Issue: https://github.com/flutter/flutter/issues/116381
- add sw rendering pixel format support
- add new backing store type that contains struct_size and pixel format
- add new public pixel format enum with the common pixel formats supported by skia
Roll Swiftshader, ANGLE, and Vulkan deps.
Updates license bot for new locations of licenses and new files
in roll.
Converts unit test harnesses to use SwANGLE, which is the
supported way of using SwiftShader as a software backend for GLES.
Updates goldens due to swiftshader changes.
Fixes up include paths to avoid directly including third_party
code by that name, which is unlikely to work in other build
environments.
Includes upstream patches to ANGLE and SwiftShader to build in our
windows environments, as well as patches to Skia to support
defining the location of VulkanMemoryAllocator and a patch to ANGLE
to support opting into a newer version of VMA.
Previously, using Platform.executable (from dart:io) returned null (if
non-null-by-default was disabled) or threw an exception (if NNBD was
enabled) since we weren't setting it.
We now pass the executable name to Dart during VM startup based on the
first value in the FlutterProjectArgs::command_line_argv array passed to
FlutterEngineRun (or FlutterEngineInitialize) on startup. argv[0] (if
specified) is explicitly documented as being required to be the
executable name in embedder.h. In the case where no argv[0] is
specified, we instead set Platform.executable to "Flutter" in order to
avoid violating the (non-nullable) type annotation on
Platform.executable.
Note that dart::bin::SetExecutableName() does NOT make a copy of the
input string, so that value needs to be available for the entire lifetime
of the VM.
This also adds EmbedderConfigBuilder::SetExecutableName() to support
setting a fake executable name in unittests. By default, we continue to
set the name "embedder_unittest" unless overridden using this method.
See: https://api.flutter.dev/flutter/dart-io/Platform/executable.html
See: https://github.com/dart-lang/sdk/issues/48427
Issue: https://github.com/flutter/flutter/issues/83921
This PR changes how embedder API's SendKeyData sends ui.KeyData to the framework. The packets are now sent over the existing platform messenger, reusing the entirety of its code path and functionalities while keeping the embedder API unchanged
Context creation options for each backend were spread across multiple
translation units. This makes setting options common across all backends hard to
configure. I have moved the creation of such common options into a separate
translation unit.
Fixes https://github.com/flutter/flutter/issues/84213
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
