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
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
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.
The EGL context will be used by other threads during test execution, and it
should not be active on multiple threads at the same time. This was not
noticed previously because SwiftShader was not checking for this, but other
EGL implementations may enforce this constraint.
In MakeSkSurfaceFromBackingStore and other places in embedder.cc, we
call a texture or framebuffer destruction callback without first
verifying it's non-null. This adds a check before such calls.
Currently fl_renderer_gl_create_backing_store() in the Linux GTK
embedder and ExternalTextureGL::PopulateTexture() in the Windows
embedder either explicitly or implicitly set a null destruction
callback.
This prevents a crash reported when running under OpenGL ES 2.0 reported
in https://github.com/flutter/flutter/issues/76881.
While this prevents the crash, it does not fix the underlying issue.
Corrects uses of setup as a verb to 'set up', leaves noun/noun-phrase
forms of setup as 'setup'. Also settles on 'teardown' as opposed to
tear-down for consistency across the codebase.
A few other minor comment/wording corrections.
This change adds a FlutterMetalRendererConfig that lets embedders
specify metal as rendering api.
Also adds a test that validates rendering a gradient using metal.
Sends the flutter/settings update message to the engine after starting
it. For now values other than 24-hour time preference are hard-coded,
but dark mode support can be added later.
Fixes https://github.com/flutter/flutter/issues/65590
* Revert "Remove GetExternalViewEmbedder from surface (#22272)"
This reverts commit 9dffddd08d0ad6fa7434c5a5bdff87e09da92e57.
* Revert "Rasterizer is initialized with an external view embedder (#22405)"
This reverts commit 417c869d6bcd70ba82fdd6efc8db1efa19fb997c.
This re-lands #20496 and #21780 after fixing the semantics-enabling code that was causing the post-submit web_smoke_test to fail.
Below is the description from the original PR:
This is a PR for converting the dart:ui code in the engine to use a multi-window API. The goal here is to convert from the window singleton to an API that has the concept of multiple windows. Also, I'm matching up the new PlatformDispatcher class to talk directly to the PlatformConfiguration class in the engine. I'm not attempting to actually enable creating multiple windows here, just migrate to an API that has a concept of multiple windows. The multi-window API in this PR currently only ever creates one window.
The design doc for this change is here.
The major changes in this PR:
Move the platfom-specific attributes out of Window, and into the new PlatformDispatcher class that holds all of the platform state, so that the platform code need only update the configuration on this class.
Create FlutterView, FlutterWindow, and SingletonFlutterWindow classes to separate out the concepts of a view (of which there may be multiple in a window), a window (of which there may be multiple on a screen, and they host views), and a window where there is only ever expected to be one (this hosts the entire API of the former Window class, and will eventually be the type of the window singleton).
Next step after this PR lands:
Remove the Window class entirely (it is replaced by SingletonFlutterWindow). Some minor changes in the Framework are needed to switch to using SingletonFlutterWindow directly first.
The Window class still exists in this PR, but will be removed as soon as the framework is converted to point to the SingletonFlutterWindow class instead. They share the same API, just have different names (Window is currently a subclass of SingletonFlutterWindow). The intention is that the Window name will be freed up to use as a widget class name in the framework for managing windows. The singleton called window will remain, and keep the same API it has now.
Embedders that have access to the Dart native API (only Fuchsia now) may perform
library setup in the isolate create callback. The engine used to depend on the
fact the root isolate entrypoint is invoked in the next iteration of message
loop (via the `_startIsolate` trampoline in `isolate_patch.dart`) to ensure that
library setup occur before the main entrypoint was invoked. However, due to
differences in the way in which message loops are setup in Fuchsia, this
entrypoint was run before the callback could be executed. Dart code on Fuchsia
also has the ability to access the underlying event loops directly. This patch
moves the invocation of the create callback to before user dart code has a
chance to run. This difference in behavior on Fuchsia became an issue when the
isolate initialization was reworked in https://github.com/flutter/engine/pull/21820
for null-safety.
Another issue was discovered in that the callback was being invoked twice, I
fixed that too and added a test.
Fixes https://github.com/flutter/flutter/issues/68732
Snapshots compiled with sound null-safety enabled require changes to the way in
which isolates are launched. Specifically, the `Dart_IsolateFlags::null_safety`
field needs to be known upfront. The value of this field can only be determined
once the kernel snapshot is available. This poses a problem in the engine
because the engine used to launch the isolate at shell initialization and only
need the kernel mappings later at isolate launch (when transitioning the root
isolate to the `DartIsolate::Phase::Running` phase). This patch delays launch of
the isolate on the UI task runner till a kernel mapping is available. The side
effects of this delay (callers no longer having access to the non-running
isolate handle) have been addressed in this patch. The DartIsolate API has also
been amended to hide the method that could return a non-running isolate to the
caller. Instead, it has been replaced with a method that requires a valid
isolate configuration that returns a running root isolate. The isolate will be
launched by asking the isolate configuration for its null-safety
characteristics.
A side effect of enabling null-safety is that Dart APIs that work with legacy
types will now terminate the process if used with an isolate that has sound
null-safety enabled. These APIs may no longer be used in the engine. This
primarily affects the Dart Convertors in Tonic that convert certain C++ objects
into the Dart counterparts. All known Dart Converters have been updated to
convert C++ objects to non-nullable Dart types inferred using type traits of the
corresponding C++ object. The few spots in the engine that used the old Dart
APIs directly have been manually updated. To ensure that no usage of the legacy
APIs remain in the engine (as these would cause runtime process terminations),
the legacy APIs were prefixed with the `DART_LEGACY_API` macro and the macro
defined to `[[deprecated]]` in all engine translation units. While the engine
now primarily works with non-nullable Dart types, callers can still use
`Dart_TypeToNonNullableType` to acquire nullable types for use directly or with
Tonic. One use case that is not addressed with the Tonic Dart Convertors is the
creation of non-nullable lists of nullable types. This hasn’t come up so far in
the engine.
A minor related change is reworking tonic to define a single library target.
This allows the various tonic subsystems to depend on one another. Primarily,
this is used to make the Dart convertors use the logging utilities. This now
allows errors to be more descriptive as the presence of error handles is caught
(and logged) earlier.
Fixes https://github.com/flutter/flutter/issues/59879
This removes most of the remaining FLUTTER_NOLINT comments and opts
these files back into linter enforcement.
I've filed https://github.com/flutter/flutter/issues/68273 to require
that all FLUTTER_NOLINT comments be followed by a GitHub issue URL
describing the problem to be fixed.
* Revert "Fix documentation build for window changes. (#21780)"
This reverts commit a539d91840d2fbbb4aa07eeed6a92d654db167ab.
* Revert "Migration to PlatformDispatcher and multi-window (#20496)"
This reverts commit a58fec63f196175eedfc5fbaedce9336dab5c508.
This is a PR for converting the dart:ui code in the engine to use a multi-window API. The goal here is to convert from the window singleton to an API that has the concept of multiple windows. Also, I'm matching up the new PlatformDispatcher class to talk directly to the PlatformConfiguration class in the engine. I'm not attempting to actually enable creating multiple windows here, just migrate to an API that has a concept of multiple windows. The multi-window API in this PR currently only ever creates one window.
The design doc for this change is here.
The major changes in this PR:
Move the platfom-specific attributes out of Window, and into the new PlatformDispatcher class that holds all of the platform state, so that the platform code need only update the configuration on this class.
Create FlutterView, FlutterWindow, and SingletonFlutterWindow classes to separate out the concepts of a view (of which there may be multiple in a window), a window (of which there may be multiple on a screen, and they host views), and a window where there is only ever expected to be one (this hosts the entire API of the former Window class, and will eventually be the type of the window singleton).
Next step after this PR lands:
Remove the Window class entirely (it is replaced by SingletonFlutterWindow). Some minor changes in the Framework are needed to switch to using SingletonFlutterWindow directly first.
The Window class still exists in this PR, but will be removed as soon as the framework is converted to point to the SingletonFlutterWindow class instead. They share the same API, just have different names (Window is currently a subclass of SingletonFlutterWindow). The intention is that the Window name will be freed up to use as a widget class name in the framework for managing windows. The singleton called window will remain, and keep the same API it has now.
