This is a reland of https://github.com/flutter/flutter/pull/177738 with
a fix to the `Op` function in `tools/path_ops`.
To match the previous behavior, `Op` will use `SkPathBuilder::operator=`
to copy the result path so that attributes like the fill type will be
copied.
---------
Co-authored-by: Kaylee Lubick <kjlubick@users.noreply.github.com>
Expose flutter Semantics.identifier as
AXPlatformNodeDelegate::AuthorUniqueId.
To be used for UI test automation through Windows AutomationId.
see https://github.com/flutter/flutter/issues/148763
followup to https://github.com/flutter/flutter/pull/161955
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
This depends on the implicitly generated `operator!=` from `operator==`
in a few cases (see the exceptions below) and add `operator<=>` in some
of the more obvious instances.
I've tried to be extremely conservative in this first pass. There are a
few more candidates that were not converted because:
* `operator!=` was different from `!operator=.` For instance, if it had
early returns. Not sure how the compiler generated those and didn't want
the behavior or performance characteristics to change.
* They were virtual.
* `operator==` didn't actually compare all struct members. Dubious but I
didn't want to change existing behavior.
* There were template parameters.
This library isn't used anywhere and will be deleted here:
https://github.com/flutter/flutter/pull/174896
I'm removing the "terms of use" wording to unblock the G3 roll while I
investigate the failures on the full deletion PR.
`git ls-files "*.gn*" | xargs ./flutter/third_party/gn/gn format`
We already seem to enforce GN format on pull-requests. These seem to old
files in the buildroot no one has touched in a while.
The changes:
* Creating a bit-mask with different enum values is now a warning. Fixed
offending instances.
* `char8_t` is a different type. Fixed those instances.
* Disabling modules in Objective-C requires bypassing the driver.
* Aggregate initialization fails when there are other constructors for
structs. Added explicit constructors.
* `gn format` doesn't seem to be run on erstwhile buildroot GN files.
Fixes the formatting. But can back this out since it is technically
unrelated to C++20.
This is the current (initial) state of WebParagraph project which is an
implementation of SkParagraph
on top of TextCluster
(https://github.com/fserb/canvas2D/blob/master/spec/enhanced-textmetrics.md).
Multilined text, mixed LTR/RTL text supported.
---------
Co-authored-by: Mouad Debbar <mdebbar@google.com>
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...).
