This produces a build of Skwasm that works on Firefox and Safari. This
means we use `SkAnimatedImage` for animated gifs and webps and use
builtin ICU data in Skia.
I have unit test suites for Safari and Firefox with dart2wasm and both
`ui` and `engine` test sets. However, there are a few issues with
running these on CI:
* Safari+dart2wasm doesn't work yet until the CI bots are upgraded to
macOS 15, so these have been disabled on CI for now (but you can run the
unit test suite locally).
* Firefox+ui doesn't work because our Linux bots have no GPU and
therefore no WebGL2 support, so that one is disabled. Firefox+dart2wasm
with the `engine` suite is enabled on CI though.
I did make some changes to the host page for our unit test harness so
that Safari actually works though. Even though we're not running on CI,
you can still run locally if you have macOS 15.
In this PR:
- `felt build --experimental-webparagraph` builds a 3rd variant of
CanvasKit to be used for `WebParagraph`.
- `felt test --suite=chrome-dart2js-experimental-webparagraph-ui` runs
`test/ui/` tests against `WebParagraph`.
- `felt test --suite=chrome-dart2js-experimental-webparagraph-ui` runs
Chrome with the extra flag:
- `--enable-experimental-web-platform-features`
In the future:
- Upgrade to Chrome@133.0.6943.53 or above.
- Actual implementation and tests of WebParagraph coming in
https://github.com/flutter/flutter/pull/167559
- Run the `chrome-dart2js-experimental-webparagraph-ui` suite in CI.
- Trim the new experimental build of CK to realize the reduction in
size.
Changes required for this roll:
* addition of LLVM libc (which is now a dependency of libcxx)
* updates the to license script
* patching the verify_exported check to allow some symbols added by
libcxx
* annotations for clang-tidy warnings
This switches skwasm over from the emscripten pthreads implementation to
emscripten's "wasm workers" threading implementation. The pthreads
implementation simply will not run at all in a non-crossOriginIsolated
context, but the wasm workers implementation only fails if we actually
attempt to spawn a thread. This means we can actually choose whether to
use a single-threaded or multi-threaded strategy at runtime, which means
we don't have to build two variants of skwasm for single- vs
multi-threaded.
<!-- start_original_pr_link -->
Reverts: flutter/flutter#163890
<!-- end_original_pr_link -->
<!-- start_initiating_author -->
Initiated by: jason-simmons
<!-- end_initiating_author -->
<!-- start_revert_reason -->
Reason for reverting: et and related packages in
https://github.com/flutter/flutter/tree/master/engine/src/flutter/tools
need to be updated for the new Ninja path
<!-- end_revert_reason -->
<!-- start_original_pr_author -->
Original PR Author: jason-simmons
<!-- end_original_pr_author -->
<!-- start_reviewers -->
Reviewed By: {matanlurey, jtmcdole}
<!-- end_reviewers -->
<!-- start_revert_body -->
This change reverts the following previous change:
The depot_tools Ninja wrapper looks for Ninja at specific paths within
the tree. The use of "name": "." in the engine's .gclient file is not
expected by the depot_tools logic for locating the engine's source
directory.
This PR creates an alternative layout that is supported by depot_tools.
If the project root directory contains a "buildtools" subdirectory, then
depot_tools will look for Ninja at "third_party/ninja" within the root.
Fixes https://github.com/flutter/flutter/issues/163487
<!-- end_revert_body -->
Co-authored-by: auto-submit[bot] <flutter-engprod-team@google.com>
The depot_tools Ninja wrapper looks for Ninja at specific paths within
the tree. The use of "name": "." in the engine's .gclient file is not
expected by the depot_tools logic for locating the engine's source
directory.
This PR creates an alternative layout that is supported by depot_tools.
If the project root directory contains a "buildtools" subdirectory, then
depot_tools will look for Ninja at "third_party/ninja" within the root.
Fixes https://github.com/flutter/flutter/issues/163487
Delete remaining DlCanvas method overloads that were allowing the use of
Skia geometry objects in rendering code.
The only remaining uses of Skia classes in the DlCanvas interface are
SkImageInfo and SkTextBlob.
These cause ambiguous compiler reference errors on some GCC versions.
And, the errors seem right. But, newer versions of clang seem to resolve
that ambiguity by also checking if the references to the types are also
references to identical types.
Per the chat with Jim, also added the Dl prefix to those types.
No change in functionality. Just a rename of the types and removal of
the now unnecessary typedefs.
Fixes a couple issues in the skwasm build rules:
* `DEMANGLE_SUPPORT` is deprecated in emscripten, so just remove it.
* `sSHARED_MEMORY=1` needs to be added to the cflags so that emscripten
appends the proper feature flags (`-matomics` and `-mbulk-memory`) when
doing the compile so that the flags match the linking step.
This fixes a race that can happen if Dart invokes an isolate's message
handling callback during isolate shutdown. The callback installed by
Tonic will invoke a dispatcher set by the engine's
DartIsolate::SetMessageHandlingTaskRunner, which will queue a message
handling task to the designated task runner.
If the queued task runs after DartIsolate::Shutdown has been called,
then Tonic's DartMessageHandler::OnHandleMessage will fail when it tries
to enter the isolate.
DartIsolate will set a shutdown flag on the DartState when Dart invokes
the isolate's shutdown callback. Tonic can avoid this race by checking
that flag before proceeding with message handling.
Fixes https://github.com/flutter/flutter/issues/160003
This PR makes a few different changes to make building the web engine
via `et` a bit smoother:
* Adds a few build steps to `local_engine.json` so that et can build
`wasm_release` and `wasm_debug_unopt` builds on Linux and Mac locally.
* Removed the part of our `generate_builder_json` step which generates
the `linux_web_engine_build.json` file. This previously used to be
generated based off of the contents of `felt_config.yaml` but now it's
just not parameterized at all, so there is no benefit to generating it
and we can just manually maintain the file now.
* Fixed an issue where the skwasm debug build was failing due to a wrong
output file being specified in the gn rule.
Roll dart to 470117150f34d712ee6d8c4558b3c656d973f656
Changes since last roll
```
470117150f3 Version 3.7.0-208.0.dev
10867627709 CHANGELOG: move AOT invocation bits to the end of the 3.7 section
83863711d3b Migrate NotImportedCompletionPass.
e01bbdfd1f4 Deprecate completions from plugins api.
2a2905228fb Add extension on Completer to simplify code.
05696d50ccf Migrate postfix_completion.dart, statement_completion.dart.
ed49d04e2e0 [analysis_server] Extract some shared code from editableArguments to be used by editArgument
c54255fe9db [element model] migrate `prefer_asserts_in_initializer_lists`
eaf3912b5d6 [deps] rev core, ecosystem, glob, http_multi_server, lints, markdown, package_config, pool, protobuf, pub_semver, shelf, source_maps, source_span, stack_trace, stream_channel, string_scanner, sync_http, term_glyph, test, test_descriptor, test_process, test_reflective_loader, tools, vector_math, watcher, web, web_socket_channel, webdriver, webkit_inspection_protocol, yaml, yaml_edit
11a11259724 Switch boringssl to the pre-generated GN source list.
a635ccf2f57 [analysis_server] Only mark positional arguments as editable if they wouldn't require inserting additional values
619c8511aba [analysis_server] Add tests for formatter language version for legacy protocol
a8f5e64a330 Roll Fuchsia Test Scripts from 6FgM4KTbxxmyYoiOs... to VilXq4eGH5A24wRWA...
623c574b817 [vm] Clean up few isolate fields.
bfb507a3af9 Migrate utilities.dart
06caa3fa11e [DAS] Adds new import with show option
0197beaa8e0 [flow analysis] Remove _typeContains method.
56b6e5b9f60 Json codable no type assumption in custom fromJson
e013a4c9bfa [analysis_server] Add some notes on how to use the CPU Profiler for the analysis server hosted by VS Code
0f723b3ef3c [vm] Fix build on gcc 14.2.0.
```
This is manual roll because dart_boringssl_gen_rev is no longer present
in dart sdk DEPS has to be removed from flutter engine DEPS manually.
While recently updating the DlColorSource sources I noticed some questionably implementation choices in the Color variant of the color sources.
I then realized that there was no public use of these classes (other than mostly their own unit tests) and so they should be deleted to focus on implementing the variants that are actually used by Flutter.
Internal bug: b/380745221
The use of `malloc` in L70:
d48ceb1ba2/third_party/tonic/filesystem/filesystem/file.cc (L70)
Results in the following error, after an update to the internal toolchain. For some reason, this error only appears when targeting Linux.
```
tonic/filesystem/filesystem/file.cc:70:28: error: use of undeclared identifier 'malloc'
70 | uint8_t* ptr = (uint8_t*)malloc(file_size);
| ^
1 error generated.
```
This PR fixes it by including the header file.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The DlColorSource code uses Skia geometry classes for its internal computations. This PR switches those implementations to use the Impeller geometry classes for consistency and 3rd party header file independence.
Enables the `-fobjc-arc` compiler flag for Objective-C and Objective-C++
translation units.
Eliminates the flutter_cflags_objc[c]_arc settings, since they're now
redundant.
All Obj-C/Obj-C++ code in our codebase has now been migrated to ARC.
Issue: https://github.com/flutter/flutter/issues/137801
Ensure that all Objective-C code in the codebase is being built with the standard set of Flutter Objective-C compiler flags with ARC enabled.
Also bumps the cflags config up to the top of the first block within each target in which Objective-C sources appear, so that the location is consistent.
Migrates The following targets to ARC, which had been missed in previous passes since they didn't declare the standard Flutter Obj-C[++] cflags:
* `//flutter/fml:fml_unittests`
* `//flutter/impeller/golden_tests:metal_screenshot`
* `//flutter/impeller/playground:playground`
* `//flutter/impeller/backend/metal:metal`
* `//flutter/impeller/backend/metal:metal_unittests`
* `//shell/gpu:gpu_surface_metal_unittests`
* `//flutter/shell/platform/embedder:embedder_unittests`
This patch includes no semantic changes.
Issue: https://github.com/flutter/flutter/issues/137801
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This attempts to reland the single-threaded Skwasm PR: https://github.com/flutter/engine/pull/56206
The main changes here are in the second commit:
* We need to actually bundle the `skwasm_st` artifacts in `flutter_web_sdk.zip`
* The `locateFile` hack no longer works since emscripten doesn't actually create a worker.js file anymore. So instead, that has been modified to use the `mainScriptUrlOrBlob` module API to do a very similar hack.
Note: I did presubmit testing with the framework CI and it appears the pertinent tests pass. See https://github.com/flutter/flutter/pull/157967
Reverts: flutter/engine#56206
Initiated by: jonahwilliams
Reason for reverting: failing to roll into framework: https://github.com/flutter/flutter/pull/157919
Original PR Author: eyebrowsoffire
Reviewed By: {harryterkelsen}
This change reverts the following previous change:
This PR creates a single-threaded version of the skwasm renderer, appropriate for non-crossOriginIsolated browsing contexts.
* The single threaded renderer is essentially the same as the multi-threaded renderer, except instead of spawning a web worker and posting messages to it, it simply schedules microtasks on the main thread in their place.
* The new renderer is vended as `skwasm_st.js` and `skwasm_st.wasm` in the same location as multithreaded skwasm. In order to properly build and function, we needed some fixes I put into emscripten that landed in version 3.1.70. That version also changed some behavior that required a few fixes to the CanvasKit build files.
* The skwasm loader in flutter.js has been modified to use the skwasm_st variants when encountering a non-crossOriginIsolated context but a browser and configuration that otherwise would allow the use of skwasm. I also added a new `forceSingleThreadedSkwasm` option to the flutter configuration so that we can override this behavior, especially so that we can accurately benchmark the single threaded renderer in a crossOriginIsolated environment.
* I also consolidated a bunch of our shards that run tests to just have one per browser/platform combination, so four total. This will address https://github.com/flutter/flutter/issues/124682
This PR creates a single-threaded version of the skwasm renderer, appropriate for non-crossOriginIsolated browsing contexts.
* The single threaded renderer is essentially the same as the multi-threaded renderer, except instead of spawning a web worker and posting messages to it, it simply schedules microtasks on the main thread in their place.
* The new renderer is vended as `skwasm_st.js` and `skwasm_st.wasm` in the same location as multithreaded skwasm. In order to properly build and function, we needed some fixes I put into emscripten that landed in version 3.1.70. That version also changed some behavior that required a few fixes to the CanvasKit build files.
* The skwasm loader in flutter.js has been modified to use the skwasm_st variants when encountering a non-crossOriginIsolated context but a browser and configuration that otherwise would allow the use of skwasm. I also added a new `forceSingleThreadedSkwasm` option to the flutter configuration so that we can override this behavior, especially so that we can accurately benchmark the single threaded renderer in a crossOriginIsolated environment.
* I also consolidated a bunch of our shards that run tests to just have one per browser/platform combination, so four total. This will address https://github.com/flutter/flutter/issues/124682
Switch from using the clumsy manual CacheablePath object to a more automatic DlPath object for holding paths in DisplayLists and dispatching them to either Skia or Impeller with auto-conversion.
For now DlPath is just a wrapper around SkPath with an auto-generating Impeller Path object which is very similar in design from what was done with the CacheablePath object except that it manages the caching of the Impeller path internally without extra burden on Impeller or Skia. There is also no need to communicate with the Dispatch method as to which type of path you prefer, they're all "auto-converting" DlPath objects now.
For now, ui.Path still generates an SkPath and so we wrap it when we record it into a DisplayList, just like the former CacheablePath mechanism. It will be a simple conversion to create the DlPath wrapper in ui.Path, though, so as to maintain the cached Impeller paths across frames even if the DisplayList itself is not preserved.
Eventually DlPath will take on more of a role of hiding the construction and internal representation of the paths so that we could be using SkPath, impeller::Path, or some other internal storage. For now, SkPath will likely remain primary storage for a while so that we can deal with PathOps.
Wean the DlOpReceiver interface and implementations off of using the SkScalar, Sk[I]Rect, and SkPoint objects in favor of our own DL/Impeller versions.
The start of an ongoing effort to eventually compartmentalize all use of Skia interfaces into a single backend rendering module that is one of 2 semi-pluggable renderers.
For very thin stroked text we switch to skia font rasterization for higher fidelity. However and very large stroke widths, the fidelity loss doesn't matter and may be much slower due to software rasterization.
As several users have noticed, there is a maximum size limit of skia stroked text that we hit as well. This only seems to happen on large stroke widths.
Fixes https://github.com/flutter/flutter/issues/153784
With this minor addition to the DlCanvas/DisplayList API the code in the paragraph builder no longer needs to worry about PathEffect objects and their varying support on the backends.
At this point all PathEffect code in the engine is obsolete and can be deleted, but I'll leave that for a follow-on PR.
The only PathEffect related thing I did delete was support for rendering primitives with a PathEffect in the DL Rendering tests, both because it is a vestigial attribute and also because it would interfere with the new DrawDashedLine rendering test (a PathEffect on top of a PathEffect...).
Multiple fixes to text rendering that match skia behavior on almost all bugs I've found, except for the glyphs are still _slightly_ too fine for some CJK text. The fixes are:
1. Compute the gylph size in the typographer context, using text size * scale factor text, instead of computing smaller bounds and scaling it up. This was not accurate and as a result we would positon glyphs incorrect by multiple pixels sometimes, causing uneven rows.
2. Match Skia's rounding behavior. previously we were rounding in multiple places, Skia rounds once. This is important to prevent jumping.
3. Use 4 subpixel X positions for rendering. This is the big one that ensures the visible layout matches exactly. Adds support for Y, both, and none positioning too. I couldn't find any examples of just Y or both. Some fonts may specify that have no subpixel positioning. So we don't bother to compute it for those.
Fixes https://github.com/flutter/flutter/issues/138386 / mostly, except slightly not bold enough.
Fixes https://github.com/flutter/flutter/issues/147577 / mostly, except slightly not bold enough.
Fixes https://github.com/flutter/flutter/issues/140475
Fixes https://github.com/flutter/flutter/issues/141467
Fixes https://github.com/flutter/flutter/issues/135523
Fixes https://github.com/flutter/flutter/issues/127815
Fixes https://github.com/flutter/flutter/issues/126546
Track the paint color used by Bitmap/Emoji/COLR fonts and use it as a cache key. This allows non-COLR glyphs in a COLR font to get the correct text color. For other kinds of fonts, we always record the color as black so there are no cache efficiency hits in general.
### Motivation of the change:
Both dart and flutter are using fairly outdated gn-sdk without properly maintained. Currently @hjfreyer is working on version'ed IDK / SDK libs which requires changes in gn-sdk to use the right version of the libs in fuchsia/sdk/obj/{arch}-api-{level} rather than the one in the fuchsia/sdk/arch. But current implementation does not support choosing the right version.
### Blocking issue:
The new gn-sdk (in flutter/tools/fuchsia/gn-sdk) generates multiple BUILD.gn files rather than a large BUILD.gn the previous version created. So most of the build rules need to switch from the old `fidl:{api}` build rule to `fidl/{api}` rule. The same change will happen in the dart/sdk, i.e. http://go/dart-reviews/356924. But since the two repos cannot have one single atomic change, changing either side first will cause flutter to break. E.g. the linkage error caused by duplicated symbols will happen if we change the dart/sdk first, since in flutter, it will still refer to the old build rules in the middle.
### Solutions:
Ideally we can create redirect rules in the current `build/fuchsia` buildroot tree to redirect the old rules into the new one, so we can make the change in the flutter first then dart/sdk. But creating the rules is not trivial and will only be used once.
So an alternative solution is
- pause the dart/sdk -> flutter roll
- submit dart/sdk change (http://go/dart-reviews/356924)
- update this change to manually bring the dart/sdk change, namely the `dart_revision` in the DEPS file and signatures in the ci/licences.
- resume the dart/sdk -> flutter roll.
But it requires this change itself to be reviewed first, and I'd like to know your opinion before moving forward.
See corresponding dart/sdk change at http://go/dart-reviews/356924.
### //build/fuchsia/ from buildroot should be removed after this change.
Bug: [b/40935282](https://issues.chromium.org/issues/40935282?pli=1&authuser=0)
FYI: @hjfreyer
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This is a prototype of the [PlatformIsolate
API](https://github.com/flutter/flutter/issues/136314).
**UPDATE (Jan 25):** The PR is ready for review. PTAL.
The `PlatformIsolate` creation flow is:
1. `PlatformIsolate.spawn` running on parent isolate
(platform_isolate.dart)
a. Create `isolateReadyPort`
b. `PlatformIsolateNativeApi::Spawn` (platform_isolate.cc)
c. `DartIsolate::CreatePlatformIsolate` (dart_isolate.cc)
d. Isolate created. Entry point invocation task dispatched to platform
thread
e. `PlatformIsolate.spawn` returns a `Future<Isolate>`
2. On the platform thread, `_platformIsolateMain` is invoked in the
platform isolate
a. Create `entryPointPort`
b. Send `Isolate.current` metadata and `entryPointPort` back to the
parent isolate via `isolateReadyPort`
3. Back in the parent isolate, `isolateReadyPort.handler` is invoked
a. Send the user's `entryPoint` and `message` to the platform isolate
via `entryPointPort`
b. Use received isolate metadata to create a new `Isolate` representing
the platform isolate and complete the `Future<Isolate>`
4. In the platform isolate, `entryPointPort.handler` is invoked
a. Run the user's `entryPoint(message)`
The engine shutdown flow is handled by `PlatformIsolateManager`, which
maintains a set of running platform isolates.
