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
* [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
Some flutter_tester scripts rely on the old value because Dart will convert
"main.dart" into a Platform.script URI containing a fully qualified path to
the script.
The old SkBase64::decode interface required the user to delete the
result of SkBase64::getData. Use the newer SkBase64::Decode interface
which makes the memory ownership more obvious.
Reland #22505, now that flutter/flutter#70637 has landed.
Removes references to dart:ui.Window, and switch usages to PlatformDispatcher or SingletonFlutterWindow, as appropriate.
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
We currently use a mix of C standard includes (e.g. limits.h) and their
C++ variants (e.g. climits). This migrates to a consistent style for all
cases where the C++ variants are acceptable, but leaves the C
equivalents in place where they are required, such as in the embedder
API and other headers that may be used from C.
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
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.
This PR touches variable names, class names, and file names so it's significantly more risky than its predecessor https://github.com/flutter/engine/pull/17329
Due to file name changes, this PR is expected to change the license files.
We haven't rename `shell/gpu` to `shell/raster` yet. It should be optional but I think it's better to have `raster_surface_software.cc` than `gpu_surface_software.cc`.
