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.
In https://github.com/flutter/flutter/issues/125361 we discovered that a
new version of clang can require updating goma in order for goma to work
properly. This PR adds a dependency on CIPD goma to the DEPS file so
that we can update it for use in local builds when needed. Since CI does
its own management of the goma client and the compiler proxy, and since
goma can only be used by Googlers, the DEPS file download is guarded
behind the `use_cipd_goma` gclient var. To use it one would update the
engine `.gclient` file to be something like:
```
~/flutter/engine/src $ cat ../.gclient
solutions = [
{
"managed": False,
"name": "src/flutter",
"url": "git@github.com:zanderso/engine.git",
"custom_deps": {},
"custom_vars": {
"use_cipd_goma": True,
},
"deps_file": "DEPS",
"safesync_url": "",
},
]
```
I'll update the wiki with these instructions after this PR lands.
Both builds are generating artifacts in the same way. This is moving the legacy builder to staging and updating Windows windows_aot_engine build to upload artifacts to prod.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Switch the root RenderPass stencil from transient to device private, add
validation logs, and dry the offscreen stencil setup. Also make the
multisample root stencil setup valid in Vulkan (the attachment
mismatched the texture -- this didn't matter before since we were always
replacing it).
Fixes a bug where the stencil gets erased between root render passes --
this issue was introduced when we removed the root blit on iOS.
Reverts https://github.com/flutter/engine/pull/40895.
Resolves https://github.com/flutter/flutter/issues/120399 (again).
A bunch of frames get pumped on the main thread _without a transaction_
just before unmerging occurs (I don't know why this happens), and so
checking the current thread to determine whether we need to present with
a transaction or not isn't sufficient. In the prior fix, after the
unmerge, the raster thread would hang for one second while waiting for
the next drawable to get freed up (happens on the second raster thread
frame post-unmerge), and then subsequent presents would just do nothing
for a while, but eventually recover.
`presentsWithTransaction` works whether the `CATransaction` stack is
empty or not, and so the only difference here is that
`presentsWithTransaction` is always turned on and `presentDrawable` is
always avoided (otherwise it tries to present too early and nothing
renders when platform views are present).
Windows host engine and windows_engine_host_engine builds are generating the artifacts using gn+ninja. This PR is sending the legacy build to staging and starts uploading the engine v2 artifacts to prod.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
dart:js_interop and package:js will start conflicting. Eventually, we
want people to only use dart:js_interop, so this CL refactors code to do
that.
Unblocks https://dart-review.googlesource.com/c/sdk/+/294130/8 and
prevents confusing shadowing of dart:js_interop annotations like we do
today.
## 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].
- [Mentioned CL that is unblocked] I listed at least one issue that this
PR fixes in the description above.
- [X] I updated/added relevant documentation (doc comments with `///`).
- [Need test-exemption] I added new tests to check the change I am
making, or this PR is [test-exempt].
- [X] All existing and new tests are passing.
