Fixes SkRSXform task in https://github.com/flutter/flutter/issues/161456
Removes (nearly) all uses of Skia SkRSXform object from DisplayList and
replaces it with a new Impeller RSTransform geometry object.
There are remaining uses in:
- Skia adapter code which needs to convert them back to SkRSXform when
using the Skia backend
- dl_rendering_tests which is waiting for a major conversion effort
- ?Fuchsia? code has an SkCanvas spy adapter used in its embedder code
(not DisplayList related)
- web_ui/skwasm
This is the last time we have to do this because in
https://github.com/flutter/flutter/pull/161554 I am refactoring the
engine's analysis_options.yaml to just import the one from the root of
the repository. When that lands, lints only have to be enabled in one
place to apply across framework and engine.
Before we can do that we have to do one last sync to make sure the
engine code base is ready. This PR implements that last sync and fixing
all lints that came up.
The situation will improve even further when we have proper ARIA roles,
but for now if a node is a leaf node and has a tap action, present it to
semantics as a button even if the `isButton` flag is missing.
Fixes https://github.com/flutter/flutter/issues/157743
`dart:ui` specifies that the translation column of the color matrix
should be in the range 0..255. Skia expects a normalized range between 0
and 1. Skwasm was not normalizing this before passing it to Skia, but
CanvasKit was. After writing a unit test, it appears that the HTML
renderer has the same problem, so I also fixed that as well.
This addresses https://github.com/flutter/flutter/issues/159697
Now that "auto" is not supported anymore, it makes more sense to make
this dart define false by default. And there's no need to pass
`FLUTTER_WEB_AUTO_DETECT=false` anymore.
This splits the web engine into a build phase and a test phase. This
requires a few changes:
* Modify the `generate_builder_json.dart` command to produce two
separate json builder files, `linux_web_engine_build.json` and
`linux_web_engine_test.json`. The former is left as the existing builder
with `release_build: true` (which will run in the merge queue) and the
latter is added as a new builder that runs in the second CI phase.
* Change the `copy_artifacts_step.dart` to pull built artifacts from the
GCS bucket when on LUCI, instead of relying on the CAS bucket. This is
necessary to do the tests separately from the build.
* Move the `felt test --copy-artifacts` command from the build steps to
the test steps, since the test steps themselves need to pull from GCS
instead of relying on the artifacts being populated by CAS.
It takes 30 minutes while all other bots are done in 10-20 minutes. The
old Windows build used to test in IE11 and old Edge. Since we stopped
testing on those we switched to Chromium, but that doesn't provide any
extra signal in addition to what we get from Linux Chromium already.
A `CkImage` instance holds a reference to `ImageSource?`. When that `CkImage` gets cloned, the `ImageSource` instance becomes shared between the original `CkImage` and its new clone. Then when one of the `CkImage`s gets disposed of, it closes the shared `ImageSource` leaving other live `CkImage`s holding on to a closed `ImageSource`.
The quick solution to this is to have a ref count on the `ImageSource` to count how many `CkImage`s are referencing it. The `ImageSource` will only be closed if its ref count reaches 0.
Fixes https://github.com/flutter/flutter/issues/160199
Fixes https://github.com/flutter/flutter/issues/158093
When running `dart format` over these lines the `// ignore` ended up on a line where it wasn't properly ignoring the lint. This adjusts the placement of `// ignore`s so they will continue to ignore the right thing even after the code is auto formatted.
I am hoping that if we do this now the large PR that formats the entire repo will go in smoother without manual intervention.
We are about to `dart format` all the Dart code in the repo, which line-breaks some of our imports.
This PR updates `sdk_rewriter.dart` to support line-broken imports.
A flaw in https://github.com/flutter/engine/pull/57153 - SkRRect would normalize the rect (make it right-side up), a feature that Flutter code takes advantage of. We need to do that manually when we ingest a round rect from Flutter.
Let's start running the tests under `engine/` using the CanvasKit renderer instead of HTML.
This PR also:
- Moves several tests from `engine/` to `html/` since they were testing html-specific stuff.
- Deletes `test/canvaskit/semantics_test.dart` since it's just an "alias" for `test/engine/semantics/semantics_test.dart`.
The Web Felt script downloads a Chrome zip archive, extracts it to a temporary directory, and then moves the files to a location expected by the script.
Previously Felt used a temporary directory based on io.Directory.systemTemp. This may not work because the FileSystemEntity.rename operation used to move the files can fail if the system temp directory is located in a different filesystem from the destination directory.
As per the [spec](https://www.w3.org/TR/png/#fcTL-chunk):
> The frame must be rendered within the region defined by x_offset, y_offset, width, and height. This region may not fall outside of the default image; thus x_offset plus width must not be greater than the [IHDR](https://www.w3.org/TR/png/#11IHDR) width; similarly y_offset plus height must not be greater than the [IHDR](https://www.w3.org/TR/png/#11IHDR) height.
All render targets created by flutter have a single color attachment. Lets specialize that case in impeller::RenderTarget by creating a field for that attachment description instead of placing it in a hashmap.
Should fix https://github.com/flutter/flutter/issues/159520 ~~but I still need to check locally.~~ Seems to do the trick.
All cmd bindings were copying the shader metadata, which meant allocating/de-allocating a lot of strings per draw.
A new source code/header structure was introduced when the DlColorSource and DlImageFilter objects were migrated to Impeller geometry classes. Even though the DlColorFilter objects did not depend on Skia geometry objects, they need to be updated to the new source layout for consistency.
Reverts: flutter/engine#56606
Initiated by: LongCatIsLooong
Reason for reverting: https://github.com/flutter/flutter/issues/159456
Original PR Author: LongCatIsLooong
Reviewed By: {chunhtai, cbracken}
This change reverts the following previous change:
This PR adds basic FKA scrolling support: when the iOS focus (the focus state is maintained separately from the framework focus, see the previous PR) switches to an item in a scrollable container that is too close to the edge of the viewport, the container will scroll to make sure the next item is visible.
Previous PR for context: https://github.com/flutter/engine/pull/55964https://github.com/user-attachments/assets/84ae5153-f955-4d23-9901-ce942c0e98ac
### Why the UIScrollView subclass in the focus hierarchy
The iOS focus system does not provide an API that allows apps to notify it of focus highlight changes. So if we were to keep using the transforms sent by the framework as-is and not introducing any UIViews in the focus hierarchy, the focus highlight will be positioned at the wrong location after scrolling (via FKA or via framework). That does not seem to be part of the public API and the focus system seems to only know how to properly highlight focusable UIViews.
### Things that currently may not work
1. Nested scroll views (have not tried to verify)
The `UIScrollView`s are always subviews of the `FlutterView`. If there are nested scrollables the focus system may not be able to properly determine the focus hierarchy (in theory the iOS focus system should never depend on `UIView.parentView` but I haven't tried to verify that).
2. If the next item is too far below the bottom of the screen and there is a tab bar with focusable items, the focus will be transferred to tab bar instead of the next item in the list
Video demo (as you can see the scrolling is really finicky):
https://github.com/user-attachments/assets/51c2bfe4-d7b3-4614-aa49-4256214f8978
I've tried doing the same thing using a `UITableView` with similar configurations but it seems to have the same problem. I'll try to dig a bit deeper into this and see if there's a workaround.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This PR adds basic FKA scrolling support: when the iOS focus (the focus state is maintained separately from the framework focus, see the previous PR) switches to an item in a scrollable container that is too close to the edge of the viewport, the container will scroll to make sure the next item is visible.
Previous PR for context: https://github.com/flutter/engine/pull/55964https://github.com/user-attachments/assets/84ae5153-f955-4d23-9901-ce942c0e98ac
### Why the UIScrollView subclass in the focus hierarchy
The iOS focus system does not provide an API that allows apps to notify it of focus highlight changes. So if we were to keep using the transforms sent by the framework as-is and not introducing any UIViews in the focus hierarchy, the focus highlight will be positioned at the wrong location after scrolling (via FKA or via framework). That does not seem to be part of the public API and the focus system seems to only know how to properly highlight focusable UIViews.
### Things that currently may not work
1. Nested scroll views (have not tried to verify)
The `UIScrollView`s are always subviews of the `FlutterView`. If there are nested scrollables the focus system may not be able to properly determine the focus hierarchy (in theory the iOS focus system should never depend on `UIView.parentView` but I haven't tried to verify that).
2. If the next item is too far below the bottom of the screen and there is a tab bar with focusable items, the focus will be transferred to tab bar instead of the next item in the list
Video demo (as you can see the scrolling is really finicky):
https://github.com/user-attachments/assets/51c2bfe4-d7b3-4614-aa49-4256214f8978
I've tried doing the same thing using a `UITableView` with similar configurations but it seems to have the same problem. I'll try to dig a bit deeper into this and see if there's a workaround.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
