The desktop artifacts are generated using gn+ninja in both the legacy and engine v2 builds. This change is making the engine v2 the primary build.
This change needs to land before https://flutter-review.googlesource.com/c/recipes/+/43340 which is removing the desktop artifacts from the legacy builder to avoid trying to upload the same artifacts multiple times.
There will be some propagation time, 1 or 2 commits where the artifacts will try to be uploaded twice making the legacy Linux Host Engine build fail and recover automatically with the auto-retry.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Reverts flutter/engine#41368
This is blocking rolls into the framework. Let's revert until we sort
out whether there's a workaround for the change to the unpremultiplied
alpha issue.
DisposeView happens every frame before laying out PlatformViews, with the order specified in `composition_order_`. Because `view_to_dispose_` is determined on UI thread and `composition_order_` is determined on the platform thread, there could be a race if the dart code on the UI thread runs faster than the rasterizer on the Platform thread, causing a view in `view_to_dispose_` is still in the `composition_order_`.
This PR delays the views in the `composition_order_` being disposed and wait for the next frame to dispose them.
fixes https://github.com/flutter/flutter/issues/125223
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
## Description
This incorporates additional signal from `Activity.onWindowFocusChanged` to help decide if the application is `resumed` or `inactive`.
When the user pulls down the notification shade or opens the app switcher in iOS, then iOS sends a notification to the application that it no longer has input focus (is no longer "active" in Apple terminology).
However, Android (at least on a Pixel) doesn't send `onPause` and `onResume` events for these things, as one might expect. Instead, this PR changes things so that we listen to `Activity.onWindowFocusChanged` and see if any of the windows still have focus.
If it doesn't have focus, then the lifecycle switches to `inactive` (even if `onPause` hasn't been called), and if it does have focus (and `onResume` hasn't been called) then we should go to `resumed`.
State changes are determined and deduped in the `LifecycleChannel` class.
Here's the old state table:
| Android State | Flutter state |
| ------------- | ------------- |
| Resumed | resumed |
| Paused | inactive |
| Stopped | paused |
| Detached | detached |
Here's the new state table:
| Android State | Window focused | Flutter state |
| ------------- | ------------- | ------------- |
| Resumed | true | resumed |
| Resumed | false | _inactive_ * |
| Paused | true | inactive |
| Paused | false | inactive |
| Stopped | true | paused |
| Stopped | false | paused |
| Detached | true | detached |
| Detached | false | detached |
* = This is the relevant change in this PR.
("Window focused" means one or more windows managed by Flutter are focused)
The `inactive` state is for when the application is running and visible, but doesn't have the input focus. An example where this currently happens are when a phone call is in progress on top of the app, or on some OEMs when going into the app switcher (I've tested on Realme and it does that, at least). With the PR, it will also go into `inactive` when the app has lost input focus, but is still in the Android `onResume` state. This means that on phones that don't pause the app when they go into the app switcher or the notification window shade (Pixel, others), the app will go into `inactive` when it didn't before. If developers weren't doing anything special in the `inactive` state before, then this PR will have no change for them. If they were, they will go into that state more often (but more consistently across OEMs).
## Related Issues
- Fixes https://github.com/flutter/flutter/issues/124591
## Tests
- Added unit tests for handling `onWindowFocusChanged`.
Skia would like to remove `SkImageGenerator::MakeFromEncoded` and this
appears to be the only remaining usage. It appears to be easily swapped
out for the `SkImages::DeferredFromEncodedData`. (skbug.com/13052)
This also removes the use of the internal `SkCodecImageGenerator` for
the public `SkCodec` API (which the image generator had just been
deferring to anyway).
While unbreaking some unit tests, I made a few assertions easier to
debug and produce nicer error messages.
The artifacts from legacy and engine v2 builders are identical. This PR is moving the legacy builder to staging and updates engine v2 build to upload the artifacts to production.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Moves onscreen stencil management from the surface to EntityPass for
Metal and Vulkan. EntityPass has enough context to set up the stencil
optimally.
Also forces us to fail loudly when the supplied stencil is set up in a
way that can't be used for rendering the pass on GLES.
- On Vulkan, when we're blitting, we don't need to set up a onscreen
stencil attachment at all.
- And on both Vulkan and Metal, the onscreen stencil can be transient
when no pass reads are necessary (fixes the benchmark regressions
introduced by https://github.com/flutter/engine/pull/41509).
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 2.2.11 to 2.3.1.
<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>
<h2>[UNRELEASED]</h2>
<p>No user facing changes.</p>
<h2>2.3.1 - 26 Apr 2023</h2>
<p>No user facing changes.</p>
<h2>2.3.0 - 21 Apr 2023</h2>
<ul>
<li>Update default CodeQL bundle version to 2.13.0. <a href="https://redirect.github.com/github/codeql-action/pull/1649">#1649</a></li>
<li>Bump the minimum CodeQL bundle version to 2.8.5. <a href="https://redirect.github.com/github/codeql-action/pull/1618">#1618</a></li>
</ul>
<h2>2.2.12 - 13 Apr 2023</h2>
<ul>
<li>Include the value of the <code>GITHUB_RUN_ATTEMPT</code> environment variable in the telemetry sent to GitHub. <a href="https://redirect.github.com/github/codeql-action/pull/1640">#1640</a></li>
<li>Improve the ease of debugging failed runs configured using <a href="https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning-for-a-repository#configuring-code-scanning-automatically">default setup</a>. The CodeQL Action will now upload diagnostic information to Code Scanning from failed runs configured using default setup. You can view this diagnostic information on the <a href="https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-the-tool-status-page">tool status page</a>. <a href="https://redirect.github.com/github/codeql-action/pull/1619">#1619</a></li>
</ul>
<h2>2.2.11 - 06 Apr 2023</h2>
<p>No user facing changes.</p>
<h2>2.2.10 - 05 Apr 2023</h2>
<ul>
<li>Update default CodeQL bundle version to 2.12.6. <a href="https://redirect.github.com/github/codeql-action/pull/1629">#1629</a></li>
</ul>
<h2>2.2.9 - 27 Mar 2023</h2>
<ul>
<li>Customers post-processing the SARIF output of the <code>analyze</code> Action before uploading it to Code Scanning will benefit from an improved debugging experience. <a href="https://redirect.github.com/github/codeql-action/pull/1598">#1598</a>
<ul>
<li>The CodeQL Action will now upload a SARIF file with debugging information to Code Scanning on failed runs for customers using <code>upload: false</code>. Previously, this was only available for customers using the default value of the <code>upload</code> input.</li>
<li>The <code>upload</code> input to the <code>analyze</code> Action now accepts the following values:
<ul>
<li><code>always</code> is the default value, which uploads the SARIF file to Code Scanning for successful and failed runs.</li>
<li><code>failure-only</code> is recommended for customers post-processing the SARIF file before uploading it to Code Scanning. This option uploads debugging information to Code Scanning for failed runs to improve the debugging experience.</li>
<li><code>never</code> avoids uploading the SARIF file to Code Scanning even if the code scanning run fails. This is not recommended for external users since it complicates debugging.</li>
<li>The legacy <code>true</code> and <code>false</code> options will be interpreted as <code>always</code> and <code>failure-only</code> respectively.</li>
</ul>
</li>
</ul>
</li>
</ul>
<h2>2.2.8 - 22 Mar 2023</h2>
<ul>
<li>Update default CodeQL bundle version to 2.12.5. <a href="https://redirect.github.com/github/codeql-action/pull/1585">#1585</a></li>
</ul>
<h2>2.2.7 - 15 Mar 2023</h2>
<p>No user facing changes.</p>
<h2>2.2.6 - 10 Mar 2023</h2>
<ul>
<li>Update default CodeQL bundle version to 2.12.4. <a href="https://redirect.github.com/github/codeql-action/pull/1561">#1561</a></li>
</ul>
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="8662eabe0e"><code>8662eab</code></a> Merge pull request <a href="https://redirect.github.com/github/codeql-action/issues/1659">#1659</a> from github/update-v2.3.1-da583b07a</li>
<li><a href="1f2f707d99"><code>1f2f707</code></a> Update changelog for v2.3.1</li>
<li><a href="da583b07a7"><code>da583b0</code></a> Add <code>workload_run_attempt</code> to analysis upload (<a href="https://redirect.github.com/github/codeql-action/issues/1658">#1658</a>)</li>
<li><a href="a9648ea7c6"><code>a9648ea</code></a> Throw full error for CLI bundle download (<a href="https://redirect.github.com/github/codeql-action/issues/1657">#1657</a>)</li>
<li><a href="c5f3f016ae"><code>c5f3f01</code></a> Merge pull request <a href="https://redirect.github.com/github/codeql-action/issues/1656">#1656</a> from github/mergeback/v2.3.0-to-main-b2c19fb9</li>
<li><a href="90f053271e"><code>90f0532</code></a> Update checked-in dependencies</li>
<li><a href="0f085f964c"><code>0f085f9</code></a> Update changelog and version after v2.3.0</li>
<li><a href="b2c19fb9a2"><code>b2c19fb</code></a> Merge pull request <a href="https://redirect.github.com/github/codeql-action/issues/1655">#1655</a> from github/update-v2.3.0-a8affb063</li>
<li><a href="b203f98343"><code>b203f98</code></a> Update changelog for v2.3.0</li>
<li><a href="a8affb0639"><code>a8affb0</code></a> Merge pull request <a href="https://redirect.github.com/github/codeql-action/issues/1649">#1649</a> from github/cklin/codeql-cli-2.13.0</li>
<li>Additional commits viewable in <a href="d186a2a36c...8662eabe0e">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 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 removes the vuln scanning action from the scorecards yaml and into its own file. The additional file already existed but was not updated.
Fixes:
b/246821537
*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
Original PR: https://github.com/flutter/engine/pull/41374
This was reverted because it broke on simulators as they do not support linear textures. To fix this, I've ifdef'd out the DeviceBufferMTL implementation of AsTexture so that it falls back to the slow path copy. Also updated the capabilities check so that the glyph atlas updates the texture contents when it changes.
Relands: https://github.com/flutter/engine/pull/41149
GN+Ninja artifacts have been validated manually. The number of files and their content is the same and presubmit tests are passing correctly in the engine and flutter.
The reason of previous reverts are:
* FlutterMacOS.framework.zip required to be double zipped.
* FlutterMacOS.dSYM.zip required to be double zipped.
* GCS cache header needed to be updated during testing.
Full details of what has been fixed can be found in: https://github.com/flutter/flutter/issues/124911
Implements partial repaint for Impeller.
Fixes https://github.com/flutter/flutter/issues/124526
The new code that manages the damage regions is more or less a copy paste from the existing Skia implementation. Compared to Skia, there are a few differences:
Normally Impeller wants to use the drawable as the resolve texture for the root MSAA pass. Unfortunately this will unconditonally clear that texture. Thus to do a partial repaint, we have to allocate a separate texture to resolve to and then blit into the drawable.
The blit seems to take about 500ns for a full screen on an iPhone 13. That implies that partial repaint is likely not worth doing if the screen is significantly changed. Thus I've added code in compositor_context.cc that computes the percentage of width or height that is part of the dirty rect. Above a threshold of (abitrarily chosen) 70%, we just render as normal. This should mean there is only a very minor hit from performing the diff on screens that are highly changed.
The other special case, is that sometimes we get damage rects that are empty - that is the drawable is already completely up to date with what we want to render. IN that case I shortcircuit all of the impeller code and just present immediately. I previously tried returning without a present but this resulted in Xcode reporting dropped frames. One caveat here is that if you use the XCode frame debugger and attempt to capture a frame where we early present, then it will claim it couldn't capture any command buffers (because we didn't create any).
To facilitate all of this, I added some additonal plumbing so that the impeller surface can get the clip rect from the submit info. Additionally, rather than using a clip rect impeller will translate and then shrink the root surface texture. This reduces memory usage compared to just clippling.
This reduces the cost of uploading the glyph atlas, as we can exploit metal's capabilies to create a texture from a device buffer and share the underlying memory with a linear texture. This also means that subsequent updates don't require uploads or copies either.
From scrolling through wonderous, this shaves off about 0.2 ms (0.6 ms -> 0.4 ms) of fresh atlas construction.
