Developers can control the backend in the following ways:
* **Do nothing**: Impeller with Vulkan is used where Vulkan is available with a fallback to Skia with OpenGL.
* **In `AndroidManifest.xml`, specify `io.flutter.embedding.android.EnableImpeller` as `false`**: Skia with OpenGL is used.
* **On the command line, specify `--no-enable-impeller`**: Skia with OpenGL is used.
Manifest options will take priority command line options when there is a conflict. This matches iOS behavior per https://github.com/flutter/flutter/issues/124049 (closed as WAI).
Fixes https://github.com/flutter/flutter/issues/149360
Part of https://github.com/flutter/flutter/issues/147883.
Excluding Fuchsia and the Web SDK, the remaining scripts are:
```sh
$ ./tools/find_pubspecs_to_workspacify.sh
/Users/matanl/Developer/engine/src/flutter/impeller/tessellator/dart/pubspec.yaml
/Users/matanl/Developer/engine/src/flutter/sky/packages/sky_engine/pubspec.yaml
/Users/matanl/Developer/engine/src/flutter/shell/vmservice/pubspec.yaml
/Users/matanl/Developer/engine/src/flutter/lib/snapshot/pubspec.yaml
/Users/matanl/Developer/engine/src/flutter/lib/gpu/pubspec.yaml
/Users/matanl/Developer/engine/src/flutter/lib/web_ui/pubspec.yaml
/Users/matanl/Developer/engine/src/flutter/flutter_frontend_server/pubspec.yaml
```
These could be the trickiest, so I'm doing them separately.
This PR does a few things. Mainly it makes the builds in
mac_host_engine.json each build fewer targets to increase parallelism
for post-submit and release builds. To ensure that increasing
parallelism doesn't lead to capacity issues, this change also allows the
mac_host_engine.json builds to run on either intel or arm64 macOS hosts.
Finally, when building on an arm64 macOS host to target macOS, this PR
changes the `gn` script to ensure that the arm64 native clang toolchain
will be used.
To keep mac_host_engine.json focused on builds that produce artifacts,
this PR also moves tests from that file into the ill-named
mac_unopt.json. In a subsequent PR, I'll rename all the *_unopt.json
files to *_tests.json or something similar.
The artifacts produced by these builds are passing framework presubmit
checks in https://github.com/flutter/flutter/pull/152345.
Replaces and closes https://github.com/flutter/engine/pull/53997.
This PR migrates the following packages to the pub workspace:
- testing/benchmark
- testing/dart
- testing/litetest
- testing/pkg_test_demo
- testing/scenario_app
- testing/skia_gold_client
- testing/symbols
- tools/golden_tests_harvester
- tools/pkg/process_fakes
It also makes minor changes to the Dart build rules in order to resolve the root package_config, instead of per-package.
I am _not_ totally confident of the `_embedder.yaml` change, but I also can't explain what is needed to continue analyzing `lib/ui` without analysis failures that all of the symbols in `dart:nativewrappers` are missing.
Fixes: https://github.com/flutter/flutter/issues/151850
Re-adding an optimization originally included in https://github.com/flutter/engine/pull/53642 that detects when ClipRRect and ClipPath operations are actually ovals and redirects them to the ClipOval path during recording to save space and reduce the need for dispatchers to do the same detections and optimizations.
GLArea.has-alpha defaults to false, which makes it impossible for a Flutter app to be transparent.
The additional change to glClearColor is to prevent a black flash when the application starts, before Flutter widgets become visible. This will also affect applications that aren't transparent, by showing the default GTK background color instead of black. This will not make the window transparent, because the developer currently has to add some code to their `linux/my_application.cc` to support transparency.
Fixes flutter/flutter#152154
Transparent windows were possible before #50754. Would it be ok to add a test for this to prevent breaking transparency again in the future?
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Reverts: flutter/engine#54067
Initiated by: jonahwilliams
Reason for reverting: disappearing fabs and background color in framework golden tests https://flutter-gold.skia.org/search?issue=152354&crs=github&patchsets=2&corpus=flutter
Original PR Author: bdero
Reviewed By: {jonahwilliams}
This change reverts the following previous change:
For each clip scope, draw opaque items in reverse order and translucent/backdrop-independent items in their original order afterwards. Clips are treated as translucent by the parent scope.
Respects clips, subpass collapse, and the clear color optimization.
### Local new_gallery before/after (iPhone 12 mini):
```
cd ~/projects/flutter/flutter/dev/integration_tests/new_gallery
flutter drive --profile --local-engine-src-path ~/projects/flutter/engine/src --local-engine=ios_profile --local-engine-host=host_profile_arm64 --trace-startup -t test_driver/transitions_perf.dart -d 00008101-000A59A93C10001E
```
SurfaceTextureGetTransformMatrix returns a col-major 4x4 matrix. We used to convert it to a 3x3 matrix. Then when applying the transformation in the shader, I'd convert it back to a 4x4 matrix.
Instead of all this (potentially lossy) flip-flopping, store the matrix just as we get it in 4x4 form and perform the conversion just once if necessary. Today, it is necessary only in the Skia backend. SkM44 already has a converter to convert to and from a 3x3 SkMatrix. So, use that instead of rolling our own.
I spent a lot of time debugging these conversions and transformations because we had rolled our own and the printers seemed to dump in row-major order irrespective of storage order. This caused a lot of confusion.
No change in functionality. Hopefully, the next person debugging transformations has an easier go at this.
For each clip scope, draw opaque items in reverse order and
translucent/backdrop-independent items in their original order
afterwards. Clips are treated as translucent by the parent scope.
Respects clips, subpass collapse, and the clear color optimization.
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 3.25.12 to 3.25.13.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/github/codeql-action/blob/main/CHANGELOG.md">github/codeql-action's changelog</a>.</em></p>
<blockquote>
<h1>CodeQL Action Changelog</h1>
<p>See the <a href="https://github.com/github/codeql-action/releases">releases page</a> for the relevant changes to the CodeQL CLI and language packs.</p>
<p>Note that the only difference between <code>v2</code> and <code>v3</code> of the CodeQL Action is the node version they support, with <code>v3</code> running on node 20 while we continue to release <code>v2</code> to support running on node 16. For example <code>3.22.11</code> was the first <code>v3</code> release and is functionally identical to <code>2.22.11</code>. This approach ensures an easy way to track exactly which features are included in different versions, indicated by the minor and patch version numbers.</p>
<h2>[UNRELEASED]</h2>
<p>No user facing changes.</p>
<h2>3.25.13 - 19 Jul 2024</h2>
<ul>
<li>Add <code>codeql-version</code> to outputs. <a href="https://redirect.github.com/github/codeql-action/pull/2368">#2368</a></li>
<li>Add a deprecation warning for customers using CodeQL version 2.13.4 and earlier. These versions of CodeQL were discontinued on 9 July 2024 alongside GitHub Enterprise Server 3.9, and will be unsupported by CodeQL Action versions 3.26.0 and later and versions 2.26.0 and later. <a href="https://redirect.github.com/github/codeql-action/pull/2375">#2375</a>
<ul>
<li>If you are using one of these versions, please update to CodeQL CLI version 2.13.5 or later. For instance, if you have specified a custom version of the CLI using the 'tools' input to the 'init' Action, you can remove this input to use the default version.</li>
<li>Alternatively, if you want to continue using a version of the CodeQL CLI between 2.12.6 and 2.13.4, you can replace <code>github/codeql-action/*@v3</code> by <code>github/codeql-action/*@v3.25.13</code> and <code>github/codeql-action/*@v2</code> by <code>github/codeql-action/*@v2.25.13</code> in your code scanning workflow to ensure you continue using this version of the CodeQL Action.</li>
</ul>
</li>
</ul>
<h2>3.25.12 - 12 Jul 2024</h2>
<ul>
<li>Improve the reliability and performance of analyzing code when analyzing a compiled language with the <code>autobuild</code> <a href="https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages#codeql-build-modes">build mode</a> on GitHub Enterprise Server. This feature is already available to GitHub.com users. <a href="https://redirect.github.com/github/codeql-action/pull/2353">#2353</a></li>
<li>Update default CodeQL bundle version to 2.18.0. <a href="https://redirect.github.com/github/codeql-action/pull/2364">#2364</a></li>
</ul>
<h2>3.25.11 - 28 Jun 2024</h2>
<ul>
<li>Avoid failing the workflow run if there is an error while uploading debug artifacts. <a href="https://redirect.github.com/github/codeql-action/pull/2349">#2349</a></li>
<li>Update default CodeQL bundle version to 2.17.6. <a href="https://redirect.github.com/github/codeql-action/pull/2352">#2352</a></li>
</ul>
<h2>3.25.10 - 13 Jun 2024</h2>
<ul>
<li>Update default CodeQL bundle version to 2.17.5. <a href="https://redirect.github.com/github/codeql-action/pull/2327">#2327</a></li>
</ul>
<h2>3.25.9 - 12 Jun 2024</h2>
<ul>
<li>Avoid failing database creation if the database folder already exists and contains some unexpected files. Requires CodeQL 2.18.0 or higher. <a href="https://redirect.github.com/github/codeql-action/pull/2330">#2330</a></li>
<li>The init Action will attempt to clean up the database cluster directory before creating a new database and at the end of the job. This will help to avoid issues where the database cluster directory is left in an inconsistent state. <a href="https://redirect.github.com/github/codeql-action/pull/2332">#2332</a></li>
</ul>
<h2>3.25.8 - 04 Jun 2024</h2>
<ul>
<li>Update default CodeQL bundle version to 2.17.4. <a href="https://redirect.github.com/github/codeql-action/pull/2321">#2321</a></li>
</ul>
<h2>3.25.7 - 31 May 2024</h2>
<ul>
<li>We are rolling out a feature in May/June 2024 that will reduce the Actions cache usage of the Action by keeping only the newest TRAP cache for each language. <a href="https://redirect.github.com/github/codeql-action/pull/2306">#2306</a></li>
</ul>
<h2>3.25.6 - 20 May 2024</h2>
<ul>
<li>Update default CodeQL bundle version to 2.17.3. <a href="https://redirect.github.com/github/codeql-action/pull/2295">#2295</a></li>
</ul>
<h2>3.25.5 - 13 May 2024</h2>
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="2d790406f5"><code>2d79040</code></a> Merge pull request <a href="https://redirect.github.com/github/codeql-action/issues/2379">#2379</a> from github/update-v3.25.13-270a29d1c</li>
<li><a href="232a8bc80e"><code>232a8bc</code></a> Update changelog for v3.25.13</li>
<li><a href="270a29d1cc"><code>270a29d</code></a> Merge pull request <a href="https://redirect.github.com/github/codeql-action/issues/2375">#2375</a> from github/update-supported-enterprise-server-versions</li>
<li><a href="58f46da2c3"><code>58f46da</code></a> Add changelog note</li>
<li><a href="f2166816d7"><code>f216681</code></a> Announce deprecation of CodeQL v2.13.4 and earlier</li>
<li><a href="8e147925e0"><code>8e14792</code></a> Merge pull request <a href="https://redirect.github.com/github/codeql-action/issues/2374">#2374</a> from github/aeisenberg/eslint</li>
<li><a href="e6663d9fa2"><code>e6663d9</code></a> Update supported GitHub Enterprise Server versions</li>
<li><a href="455bd98666"><code>455bd98</code></a> Update checked-in dependencies</li>
<li><a href="778c2bc28d"><code>778c2bc</code></a> Fix eslint configuration</li>
<li><a href="3cf7236447"><code>3cf7236</code></a> Migrate to <code>eslint.config.mjs</code></li>
<li>Additional commits viewable in <a href="4fa2a79536...2d790406f5">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
This only addresses the following:
- Removes `JSVoid` in favor of `void`. `JSVoid`, which is just a
typedef, should be deprecated and removed eventually.
- Removes extra interop methods that were needed to make sure arity was
correct. These are no longer needed as interop methods are
invocation-sensitive and calls to them do not forward more arguments
than were passed by the user.
- Removes unnecessary annotations on extensions.
Still left to do (not comprehensive):
- Migrate to extension types.
- Remove forwarding methods that are only used to convert primitives in
favor of changing the interop method to include the Dart primitive type.
It might be a bit slower in dart2wasm to do this, but will need to
verify and fix it if that's the case.
- Remove usage of `js_util`.
- See if we can replace types with their `package:web` equivalent for
easier maintenance.
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
A few non-functional clean-ups in semantics:
* Rename `RoleManager` to `SemanticBehavior`.
* Rename `PrimaryRoleManager` to `SemanticRole`.
* Remove the `Role` enum. Move the enum docs into the respective classes.
## Why?
Previous naming was confusing. It's not clear what the difference is between a "role manager" and a "primary role manager". The word "manager" is a meaningless addition; the `Semantic*` prefix is much more meaningful. The `Role` enum was only used for tests, but tests can just use `SemanticRole.runtimeType`.
## New state of the world
After this PR the semantics system has "objects" (class `SemanticsObject`), "roles" (class `SemanticRole`), and "behaviors" (class `SemanticBehavior`).
- A semantic _object_ is an object attached to the framework-side `SemanticNode`. It lives as long as the semantic node does, and provides basic functionality that's common across all nodes.
- A semantic object has exactly one semantic _role_. This role is determined from the flags set on the semantic node. Flags can change, causing a semantic object to change its role, which is why these are two separate classes. If an object had just one permanent role, we could combine these classes into one (maybe one day we'll do it, as changing roles dynamically is weird, but that needs major changes in the framework).
- A semantic role may have zero or more semantic _behaviors_. A behavior supplies a piece of functionality, such as focusability, clickability/tappability, live regions, etc. A behavior can be shared by multiple roles. For example, both `Button` and `Checkable` roles use the `Tappable` behavior. This is why there's a many-to-many relationship between roles and behaviors.
Or in entity relationship terms:
```mermaid
---
title: Semantic object relationships
---
erDiagram
SemanticsNode ||--|| SemanticsObject : managed-by
SemanticsObject ||--o{ SemanticRole : has-a
SemanticRole }o--o{ SemanticBehavior : has
```
For this to work, we need to provide our own capture scope otherwise the default scope won't capture our commands.
This is required as part of the work to switch to unmerged threads for PVs (https://github.com/flutter/engine/pull/53826), as I can confirm @knopp 's observations that the performance is much worse with the default CAMetalLayer.
Fixes https://github.com/flutter/flutter/issues/140901
