## Description
This PR calls Android API `InputMethodManager.restartInput` to reset IMEs internal states. Otherwise some IMEs (Gboard for instance) keep reacting based on the previous input configuration until a new configuration is set.
- On Android native, `restartInput` is called in several places, for instance in f219798774/android/widget/TextView.java (L2458).
- On Compose, https://github.com/flutter/flutter/issues/70546#issuecomment-1088345561 pointed out where it is called.
- On Flutter, it is called at some point but mainly when another `TextField` is focused (it is mainly called in `setTextInputEditingState`).
## Related Issue
Fixes https://github.com/flutter/flutter/issues/70546.
## Tests
Adds 1 test.
The `EXPECT_CALL_IS_EVENT` macro used features that are not supported by Visual Studio 2022's intellisense, which results in >130 errors when editing in Visual Studio. These issues only affect the editing experience, building still works as expected.
This change reduces false errors in Visual Studio by making `EXPECT_CALL_IS_EVENT` buildable in Visual Studio.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Windows's `KeyboardManager` has several top-level helper functions. These are already wrapped in an anonymous C++ namespace, which is the C++ equivalent of the C `static` keyword.
No tests are updated as this PR is a refactoring with no semantic changes.
Â
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This keeps things consistent with other imports and fixes the internal breakage (b/320443454).
While the build system here is able to handle imports both with and without the flutter prefix, the internal mechanism that rewrites these imports is currently unable to handle the latter case.
Before starting an isolate, `dart[_test]_component_controller` detects
sound null safety status for all given kernels and fails if they aren't
the same, and uses the result to set `null_safety` in isolate flags.
Also switch to `core` snapshots from `core-jit` snapshots, based on
https://github.com/flutter/engine/pull/30744, as it looks like
`core-jit` snapshots are not null safety agnostic.
See b/315776399
## 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.
Reland of https://github.com/flutter/engine/pull/49505
---
part of https://github.com/flutter/flutter/issues/140804
We can't use the existing host buffer abstraction as that requires us to collect all allocations up front. By itself, this isn't sufficient for #140804 , because we'll need a way to mark ranges as dirty and/or flush if we don't have host coherent memory. But by itself this change should be beneficial as we'll create fewer device buffers and should do less allocation in general.
The size of the device buffers is 1024 Kb, somewhat arbitrarily chosen.
Reverts flutter/engine#49505
Initiated by: jonahwilliams
This change reverts the following previous change:
Original Description:
part of https://github.com/flutter/flutter/issues/140804
We can't use the existing host buffer abstraction as that requires us to collect all allocations up front. By itself, this isn't sufficient for #140804 , because we'll need a way to mark ranges as dirty and/or flush if we don't have host coherent memory. But by itself this change should be beneficial as we'll create fewer device buffers and should do less allocation in general.
The size of the device buffers is 1024 Kb, somewhat arbitrarily chosen.
part of https://github.com/flutter/flutter/issues/140804
We can't use the existing host buffer abstraction as that requires us to collect all allocations up front. By itself, this isn't sufficient for #140804 , because we'll need a way to mark ranges as dirty and/or flush if we don't have host coherent memory. But by itself this change should be beneficial as we'll create fewer device buffers and should do less allocation in general.
The size of the device buffers is 1024 Kb, somewhat arbitrarily chosen.
All of these are non-semantics changing and all were auto-applied by
IntelliJ:
- Make always `final` stuff final
- Avoid unnecessary casts
- Annotate `@NonNull` overrides
- Avoid initializing callbacks outside of the constructor, and use Java
lambdas when applicable
- Avoid cases where something is known to be non-null or non-false
- Use `<>` when applicable
Closes https://github.com/flutter/flutter/issues/141043.
Nothing in this change should impact:
- End-user apps
- Testing and/or CI
I've added what I believe is the minimum required to get a reasonable
Android Studio experience with the `shell/platform/android` folder. More
could definitely be done, but this unblocks me (i.e.
https://github.com/flutter/flutter/issues/139702) and adds instructions
for the next person.
_I'm open to suggestions on how to improve this further, but unless they
are critical, I'd rather land this as-is and review your PRs tweaking my
documentation further (I have limited time to work exclusively on
docs)._
---
Example after this:
- Enable ImageReader/SurfaceProducer backends for Android >= 29.
- This removes the need for a weird Android 29-specific fix in
SurfaceTexturePlatformViewRenderTarget.
- Now that we don't need the weird fix we can simplify the
PlatformViewRenderTarget interface.
This change ensures that we first set the default buffer size on the
underlying SurfaceTexture before creating the Surface for it.
This fixes a bug that only occurs on Android devices running 28 or
older: see https://github.com/flutter/flutter/issues/141068.
This also removes some unnecessary init code and cleans up tests.
FlutterEngineSendKeyEvent sends a platform message. The test's embedder configuration must have a platform message callback that calls FlutterEngineSendPlatformMessageResponse to free the message's response handle.
This enables work ongoing by @derekxu16 to improve performance in flutter_tester when running multiple files from large test suites.
Specifically, it:
- Exposes a `Spawn` C symbol from flutter_tester that runs the current kernel in a new UI isolate with a different entrypoint and/or route name
- Exposes two symbols from flutter_tester to allow a test harness to more efficiently load particular kernel files or to lookup an entrypoint from an imported source file.
- Avoids re-loading the kernel file completely when spawning a new UI isolate
Googlers can look at go/flutter-tester-isolates for some more context. If anyone wants I'm happy to create a public version of that doc.
The following sequence of events would lead to a crash:
- Reader A is created.
- Reader A produces a frame (A0)
- Texture is resized.
- Reader B is created and reader A is scheduled to be closed.
- Reader A produces a frame (A1). This is skipped.
- Reader A is closed.
- Frame A0 is acquired.
Because we closed Reader A the frame A0 is invalid.
The fix is to not close Reader A when it is the last reader to produce a
frame.
Fixes internal bug b/318458306
Android Platform Views process MotionEvents in a complicated way:
1. MotionEvent is captured and delivered to
PlatformViewWrapper.onTouchEvent (TLHC) or
FlutterMutatorView.onTouchEvent (HC)
2. MotionEvent is transformed by the AndroidTouchProcessor into a
PointerEvent
3. AndroidTouchProcessor sends the PointerEvent over the
PlatformViewChannel
4. Framework processes the PointerEvent
5. Framework sends the PointerEvent over the PlatformViewChannel.
6. in PlatformViewsController.onTouch a new MotionEvent is synthesized
7. The MotionEvent is delivered to the platform view
After step (6) the MotionEvent will fail Verification
(`android.hardware.input.InputManager.verifyInputEvent`).
The fix requires that in step (6) we use the original motion event
delivered in step (1) instead of synthesizing a new instance.
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.
I tried to do this for Vulkan too but hit the limit of my patience for today on debugging why the Vulkan backend was segfaulting on shutdown.
Half of https://github.com/flutter/flutter/issues/140419
This is part of the work towards supporting OpenGLES and Vulkan for runtime stage shaders.
Removes some redundant work we had around SkSL. Now only bundles the shaders we actually ask for from the command line.
@bdero, we should figure out if this is the right approach for flutter_gpu.
With this change, the IPLR format goes from having a root table of shader related information to a root table of shader information per `sksl`, `metal`, `opengles`, and `vulkan` platforms.
This may end up allowing us to revert https://github.com/flutter/engine/pull/47278, but I'm not sure I understand all the implications of that at this point.
I have run some but not all tests locally.
This is one of a series of changes to reland https://github.com/flutter/engine/pull/47239.
This PR changes `Animator` so that if `Render` is not called after a `BeginFrame`, this call is ignored.
Note that this is slightly different from https://github.com/flutter/engine/pull/47239. Instead of saying that we should ultimately change this skip to an assertion, this PR aims to keep the skip as the final shape. This is because a while ago we (with @goderbauer and @loic-sharma) decided that `PlatformDispatcher` should contain as little logic as possible to allow testing, and instead serve as a minimal native function binding, which means that we should eventually move the code that validates calling convention to the engine.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
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.
This reverts commit 87171e73397f7edfd4c145fbaebdd7208954debf.
Internal performance test shows that this PR negatively affects startup time. I'll reland this PR in parts.
b/307872797
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
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
