This PR adds a new way to define scoped trace events in Java, using the try-with-resource construct. This makes code simpler to read, and less error-prone.
Before:
```java
try {
TraceSection.begin("name");
// ....
} finally {
TraceSection.end();
}
```
Now:
```java
try (TraceSection e = TraceSection.scoped("name")) {
// ...
}
```
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The `FlutterWindowsView` uses the `DwmFlush` win32 API to prevent artifacts during window resizing.
Currently, the view used the `FlutterWindow` to allow mocking this win32 API. However, the window is a complex type with lots of other responsibilities. The `WindowsProcTable` is the new preferred type for mocking win32 API.
Part of https://github.com/flutter/flutter/issues/140626
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The `FlutterWindowsView` needs the `DwmIsCompositionEnabled` win32 API to check whether it should block presents until the v-blank to prevent screen tearing.
Currently, the view used the `FlutterWindow` to allow mocking this win32 API. However, the window is a complex type with lots of other responsibilities. The `WindowsProcTable` is the new preferred type for mocking win32 API.
Part of https://github.com/flutter/flutter/issues/140626
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The Windows embedder has three ways to get an `HWND`:
1. `GetWindowHandle` which returns the `HWND`
2. `GetPlatformWindow` which returns the `HWND` wrapped as a `PlatformWindow`
3. `GetRenderTarget` which returns the `HWND` wrapped as a `RenderTarget`
These abstractions are no longer useful now that we removed the UWP embedder. This change removes `PlatformWindow` and `RenderTarget` and uses `HWND` directly.
This change is a refactoring with no semantic changes.
We are embedding Flutter into MacOS app, and noticed that there is a
leak. `leaks` tool says there is a cycle reference:
```
12 (2.11K) ROOT CYCLE: <FlutterKeyboardManager 0x29ec55f40> [80]
8 (432 bytes) __strong _primaryResponders --> ROOT CYCLE: <NSMutableArray 0x29ec560a0> [64]
7 (368 bytes) ROOT CYCLE: <NSMutableArray (Storage) 0x29ec56140> [32]
4 (224 bytes) ROOT CYCLE: <FlutterEmbedderKeyResponder 0x29ec56310> [80]
1 (48 bytes) __strong _sendEvent --> ROOT CYCLE: <__NSMallocBlock__ 0x29ec56360> [48]
__strong [capture] --> CYCLE BACK TO <FlutterKeyboardManager 0x29ec55f40> [80]
1 (48 bytes) __strong _pendingResponses --> <NSMutableDictionary 0x29ec563c0> [48]
1 (48 bytes) __strong _pressingRecords --> <NSMutableDictionary 0x29ec56390> [48]
2 (112 bytes) <FlutterChannelKeyResponder 0x29ec56450> [48]
1 (64 bytes) __strong _channel --> <FlutterBasicMessageChannel 0x29ec564e0> [64]
2 (1.55K) __strong _layoutMap --> <NSMutableDictionary 0x29ec56630> [48]
1 (1.50K) <NSMutableDictionary (Storage) 0x123c34a00> [1536]
1 (64 bytes) __strong _pendingEvents --> <NSMutableArray 0x29ec565f0> [64]
```
This patch uses `weak` pointer to `self` instead of implicit `strong`.
## 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] and the [C++,
Objective-C, Java style guides].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I added new tests to check the change I am making or feature I am
adding, or the PR is [test-exempt]. See [testing the engine] for
instructions on writing and running engine tests.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I signed the [CLA].
- [x] All existing and new tests are passing.
We're on a version of clang that crashes a lot on macOS. This PR rolls
clang forward to a new release from the Fuchsia toolchain team. If it
does not fix the crash, we can roll back with
https://github.com/flutter/engine/pull/49249. Both rolling forward and
back require the fixes to the `.mm` file in this PR.
related issue https://github.com/flutter/flutter/issues/111268,
https://github.com/flutter/flutter/issues/106190
### Motivation:
- At https://github.com/flutter/flutter/issues/111268, we found that
Android PlatformView scrolls slowly after #34182 commit
### Modification:
- Makes `PlatformViewsController` view to use `tracked event`'s action &
pointer count
### Result:
- Now PlatformView scrolls not slowly
- Close https://github.com/flutter/flutter/issues/111268,
https://github.com/flutter/flutter/issues/106190
- [ ] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [ ] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [ ] 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.
- [ ] 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] All existing and new tests are passing.
Co-authored-by: John McCutchan <john@johnmccutchan.com>
This PR implements `FlutterMetalLayer`, a drop-in (as far as Flutter is
concerned) replacement for `CAMetalLayer`. The biggest difference is
that `FlutterMetalLayer` can present frames from background thread
within a `CATransaction`.
`FlutterMetalLayer` is disabled by default. To opt-in, add the following
item to `Info.plist`:
```xml
<key>FLTUseFlutterMetalLayer</key>
<true/>
```
The performance seems quite good, consistent 120hz on iPhone 13 Pro.
Benefits
- presenting with transaction from background thread, which, down the
line, would allow for platform views without thread merging.
- fine control over how the surface is displayed - we can display single
surface on multiple `CALayers`, each showing different part, allowing
for performant implementation of unobstructed platform views.
Drawbacks
- this not being a metal layer makes working with metal instrument tools
more awkward
Reverts flutter/engine#48849
Initiated by: loic-sharma
This change reverts the following previous change:
Original Description:
This migrates the Windows embedder to `FlutterCompositor` so that the engine renders off-screen to a framebuffer instead of directly onto the window's surface. This will allow us to support platform views and multiple views on Windows.
<details>
<summary>Tests...</summary>
* Verify OpenGL compositor's raster time isn't regressed and memory increase is reasonable
* Software compositor's raster time and memory isn't regressed
Test device configurations
* [x] Windows 11 (hardware acceleration enabled/disabled)
* [x] Windows Arm64 (hardware acceleration enabled/disabled)
* [x] Windows 7 (hardware acceleration enabled/disabled, DWM enabled/disabled)
</details>
Addresses https://github.com/flutter/flutter/issues/128904
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Create a `PrivacyInfo.xcprivacy` (this name is required) plist and move it to the top-level of the iOS framework bundle. `NSPrivacyTracking*` and `NSPrivacyCollectedDataTypes` keys are required, but the values are blank.
Apple [now requires](https://developer.apple.com/documentation/bundleresources/privacy_manifest_files) that third-party frameworks must include this manifest to document usage of particular APIs and [how they are used](https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api).
> Starting in fall 2023, when you upload a new app or app update to App Store Connect that uses an API (including from third-party SDKs) that requires a reason, youâll receive a notice if you havenât provided an approved reason in your appâs privacy manifest. And starting in spring 2024, in order to upload your new app or app update to App Store Connect, youâll be required to include an approved reason in the appâs privacy manifest which accurately reflects how your app uses the API.
https://developer.apple.com/news/?id=z6fu1dcu
@stuartmorgan [audited](https://github.com/flutter/flutter/issues/131494#issuecomment-1852718759) the engine and third_party:
> * File timestamps:
>
> * `C617.1` for app state restoration in `FlutterAppDelegate.mm`.
> * `0A2A.1` for implementation of the relevant `File` wrappers.
> * System boot time:
>
> * `35F9.1` for various event timing and elapsed time calculations.
Note macOS frameworks do not need to declare `NSPrivacyAccessedAPITypes`.
I don't think this will require recipe or conductor codesign changes since this is a file copied as a resource into the framework, just as the modulemap and Info.plist aren't referenced anywhere.
I'm not quite sure how to test this other than letting it build and generate a `Generate Privacy Report` in a Flutter app in Xcode. There's no where we check that, say, the Info.plist is copied to the right place in Flutter.framework (even in flutter/flutter). When this rolls into the framework I will add a check to [ios_content_validation_test.dart](3da9bc1698/dev/devicelab/bin/tasks/ios_content_validation_test.dart)
On this PR the `PrivacyInfo.xcprivacy` was written to the expected location in the Flutter.framework:
d45cd08094/516/tree
Fixes https://github.com/flutter/flutter/issues/131494
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This migrates the Windows embedder to `FlutterCompositor` so that the engine renders off-screen to a framebuffer instead of directly onto the window's surface. This will allow us to support platform views and multiple views on Windows.
<details>
<summary>Tests...</summary>
* Verify OpenGL compositor's raster time isn't regressed and memory increase is reasonable
* Software compositor's raster time and memory isn't regressed
Test device configurations
* [x] Windows 11 (hardware acceleration enabled/disabled)
* [x] Windows Arm64 (hardware acceleration enabled/disabled)
* [x] Windows 7 (hardware acceleration enabled/disabled, DWM enabled/disabled)
</details>
Addresses https://github.com/flutter/flutter/issues/128904
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This PR adds `String? identifier` to `SemanticsUpdateBuilder` (currently it's only available in the temproary `SemanticsUpdateBuilderNew` API.
This is mainly targeted at https://github.com/flutter/flutter/issues/17988
Steps:
part 1: [engine] add `SemanticsUpdateBuilderNew` https://github.com/flutter/engine/pull/47961
part 2: [flutter] use `SemanticsUpdateBuilderNew` https://github.com/flutter/flutter/pull/138331
**part 3: [engine] update `SemanticsUpdateBuilder` to be the same as `SemanticsUpdateBuilderNew`** <-- we are here
part 4: [flutter] use (now updated) `SemanticsUpdateBuilder` again.
part 5: [engine] remove `SemanticsBuilderNew`
The `SurfaceProducer` interface exposes only exposes a Surface to render
on, abstracting away the consumer side of the external texture.
The `ImageReaderSurfaceProducer` implementation of this interface is
included as well as a basic test of that code.
Also, a small refactor so that `ImageTexture` and
`ImageReaderSurfaceProducer` can use the same native C++ code in the
engine.
Subsequent CLs will need to address the following:
- A SurfaceTextureSurfaceProducer (your eyes are probably bleeding from
that name) implementation is needed so we can support GL based systems.
- Update Platform Views to use this new SurfaceProducer type instead of
the legacy types.
- Deprecate SurfaceTexture and ImageTexture external texture types.
Related issue
[#139702](https://github.com/flutter/flutter/issues/139702)
This reverts commit d5d8b5de90f40644f23d309c0f68d03e299334eb.
The flutter/tests/skp_generator test (running in flutter_tester on
Linux) was failing, along with some customer tests.
The EGL context can only be used by a single thread at a time. Currently:
1. The platform thread uses the EGL context to configure the render surface when a `FlutterViewController` is created
2. The raster thread uses the EGL context to render
In a multi-view world, a `FlutterViewController` can be created in parallel to a rendering operation. This results in multiple threads attempting to use the EGL context in parallel, which can crash (see https://github.com/flutter/flutter/issues/137973).
This change configures the render surface on the raster thread if the raster thread exists (aka the engine is running).
Addresses https://github.com/flutter/flutter/issues/137973
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
GLES functions are resolved at runtime. This refactors how these functions are stored by introducing the `GlProcTable` abstraction.
This is a step towards switching the Windows embedder to `FlutterCompositor` rendering as the present callback will use the `GlProcTable` to render OpenGL backing stores.
Â
Part of https://github.com/flutter/flutter/issues/128904
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
In https://g-issues.skia.org/issues/305780908 Skia is removing the
default SkFontMgr. Previous work consolidated all references to
txt/platform.h and this replaces those last references. I attempted to
mirror the existing functionality, which still responds to GN flags and
the target platform.
After this PR, Flutter should not be depending on the default fontmgr
(and the defines in flutter_defines.gni) will maintain that behavior
until the legacy functions/methods are deleted from Skia. There were a
few tests that I missed on an earlier PR which relied on the default
font (helper added in #47493). These tests were failing because they
were making some assertions related to TextBlobs, which didn't work if
the (now-empty) Typeface they loaded had no glyphs. Thus, I added a few
extra asserts to make sure these textblobs *had* glyphs which make the
failing tests less mysterious, should this issue crop up again.
I cleaned up Flutter's BUILD.gn file for Skia a bit, deleting unused
targets related to the font managers. This involved fixing an implicit
dependency from //third_party/glfw/ to `Gdi32.lib` on Windows.
## 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] and the [C++,
Objective-C, Java style guides].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I added new tests to check the change I am making or feature I am
adding, or the PR is [test-exempt]. See [testing the engine] for
instructions on writing and running engine tests.
- [ ] I updated/added relevant documentation (doc comments with `///`).
- [x] I signed the [CLA].
- [x] All existing and new tests are passing.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#overview
[Tree Hygiene]: https://github.com/flutter/flutter/wiki/Tree-hygiene
[test-exempt]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo
[C++, Objective-C, Java style guides]:
https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
[testing the engine]:
https://github.com/flutter/flutter/wiki/Testing-the-engine
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes
[Discord]: https://github.com/flutter/flutter/wiki/Chat
Support framebuffer fetch on devices that have the extension VK_ARM_RASTERIZATION_ORDER_ATTACHMENT_ACCESS which gives us a fairly easy way to add subpass self dependencies.
Part of https://github.com/flutter/flutter/issues/120223
I was shocked this was even legal earlier. But a new Clang roll makes this an a warning which gets converted into an error.
I attempted to roll to the Clang roll the roller did and fixed the issues I found. Hopefully, the next roll is unblocked.
Original failure: https://github.com/flutter/engine/pull/48563
Sets enabled state in Fuchsia a11y via the accessibility bridge.
This was added in Fuchsia API v15, which Flutter is updated to use after
#48233.
b/261482081
## 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] and the [C++,
Objective-C, Java style guides].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I added new tests to check the change I am making or feature I am
adding, or the PR is [test-exempt]. See [testing the engine] for
instructions on writing and running engine tests.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I signed the [CLA].
- [x] All existing and new tests are passing.
This PR adds multiview support for `ExternalViewEmbedder`.
## Nomenclature
The term **view** can be ambiguous in `ExternalViewEmbedder`, and therefore the following terms are used:
* A **native view** refers to the final drawing surface that to composite layers to. It is the "view" used in other places of the engine, such as `Shell::AddView`.
* A **platform view** refers a platform view, a layer that holds content to be embedded.
## Change
The lifecycle of `ExternalViewEmbedder` is changed:
<table>
<thead>
<tr>
<th>Before PR</th>
<th>After PR</th>
<th>How it's called</th>
</tr>
</thead>
<tbody>
<tr>
<td rowspan=2>BeginFrame</td>
<td>BeginFrame</td>
<td>Once per frame</td>
</tr>
<tr>
<td>PrepareFlutterView</td>
<td>Once per flutter view</td>
</tr>
<tr>
<td>SubmitFrame</td>
<td>SubmitFlutterView (renamed)</td>
<td>Once per flutter view</td>
</tr>
<tr>
<td>EndFrame</td>
<td>EndFrame (unchanged)</td>
<td>Once per frame</td>
</tr>
</tbody>
</table>
* `BeginFrame` should perform per-frame actions, such as merge-unmerging threads.
* `PrepareView` should perform per-native-view preparations, such as recording the view ID and view size.
This change is necessary because some actions in `PrepareView` needs to be refreshed at the beginning of drawing every native view.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Accompanying framework PR: https://github.com/flutter/flutter/pull/138331
This PR implements support for exposing `SemanticsProperties.identifier` on Android as `resource-id`. Mainly targeted at https://github.com/flutter/flutter/issues/17988. Would also fix https://github.com/flutter/flutter/issues/issues/137735 but it was marked as duplicate. Anyway, there's a lot of context in that issue.
This PR requires changing the `SemanticsUpdateBuilder` interface (defined in engine) that framework depends on, so it requires introducing a temporary API ([see question I asked on Discord](https://discord.com/channels/608014603317936148/608018585025118217/1174845658033819729) to learn more about this approach).
Steps:
**part 1: [engine] add `SemanticsUpdateBuilderNew`** <-- we are here
part 2: [flutter] use `SemanticsUpdateBuilderNew`
part 3: [engine] update `SemanticsUpdateBuilder` to be the same as `SemanticsUpdateBuilderNew`*
part 4: [flutter] use (now updated) `SemanticsUpdateBuilder` again.
part 5: [engine] remove `SemanticsBuilderNew`
I'd like to do these changes first, and only then continue with [the proper framework PR](https://github.com/flutter/flutter/pull/138331).
*More specifically: update `SemanticsUpdateBuilder.updateNode()` to be the same as `SemanticsUpdateBuilderNew.updateNode()`. Number of arguments that function takes is the only change.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Adds a check to retrieve explicit text from Clipboard items via [`getText`](https://developer.android.com/reference/android/content/ClipData.Item#getText()) before attempting to retrieve data if the Clipboard item (`ClipData.Item`) has an associated URI. Also adds more error handling for edge cases concerning URIs (the URI not having the content scheme or being null).
Fixes https://github.com/flutter/flutter/issues/74320. Some content providers will not send URIs containing the `text/*` pattern or have the content scheme (`content://`), but ultimately we should expect Clipboard items to either fall **not** into one of those categories or have an explicit textual value available via `getText`. In case this is not true, though, checks for non-content URIs and null URIs are added, as well :)
Tested on a Samsung tablet with pasting from MS Word, MS Excel, and Samsung Notes.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
## Description
This PR adds support for the PlatformChannel `Share.invoke` message on Android (before this PR it is only supported on iOS).
## Related Issue
Engine side for https://github.com/flutter/flutter/issues/138728
## Tests
Adds 2 tests.
Reverts flutter/engine#48481
Initiated by: matanlurey
This change reverts the following previous change:
Original Description:
This PR adds cstdint to binary_messenger.h. Without this building plugin support for generic Linux fails. Not related to the GTK source tree.
*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
This PR adds cstdint to binary_messenger.h. Without this building plugin support for generic Linux fails. Not related to the GTK source tree.
*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
GtkApplication windows contain a reference back to the application. This
means the MyApplication object in the Flutter application never
disposes. We workaround this by removing these references before we
quit. This occurs for all GTK applications that quit using this method,
see https://gitlab.gnome.org/GNOME/gtk/-/issues/6190. This may be fixed
upstream at some point but the proposed workaround should solve the
problem for all versions and not conflict with any upstream solution.
Fixes https://github.com/flutter/flutter/issues/136582
