Fixes https://github.com/flutter/flutter/issues/142488
- Only logs on iOS if Skia is used instead of Impeller.
- Logs on other platforms if Impeller is used instead of Skia.
- Uses "IMPORTANT" rather than "ERROR" for these logs. This will show up by default since flutter_tools sets ERROR and above as logs to show.
- Adds some tests.
- Makes INFO log print file paths the same as other verbosities.
Reverts "Reland "[Fuchsia] Execute most of the testing/fuchsia/test_suites.yaml on debug and release builds"""
Reverts flutter/engine#50295
Initiated by: zanderso
Reason for reverting: Timing out on CI
Original PR Author: zijiehe-google-com
Reviewed By: {keyonghan}
This change reverts the following previous change:
Original Description:
Reverts flutter/engine#50291, https://github.com/flutter/flutter/issues/142811
Following is the original change description.
This change implements a BundledTestRunner to run most of the tests in testing/fuchsia/test_suites.yaml as ExecutableTestRunner.
- Tests with packages out of out/fuchsia_*_x64/ are ignored for now.
- Tests with extra test command line parameters are ignored for now.
The BundledTestRunner can share most of the logic in ExecutableTestRunner and avoid reinventing the wheel.
This change also fixes the build break of fuchsia_tests in fuchsia_release_x64 which allows tests to run on the build as well.
- Tests not built with AOT are filtered out with variant field in test_suites.yaml.
Bug: https://github.com/flutter/flutter/issues/140179
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Update Fuchsia's API level to 16.
b/322503140
## 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.
## Description
This PR fixes an issue where keystrokes aren't received on Android
devices with physical keyboards (e.g. rugged Zebra devices) when
`keyboardType` is set to `TextInputType.none` on a `TextField`.
The logic in `setTextInputClient` and `canShowTextInput` created an
`inputTarget` with `InputTarget.Type.NO_TARGET` which caused the [input
connection to short
circuit](https://github.com/flutter/engine/blob/main/shell/platform/android/io/flutter/plugin/editing/TextInputPlugin.java#L296)
and not be established.
Bug introduction PR: https://github.com/flutter/engine/pull/26585
## Related Issue
https://github.com/flutter/flutter/issues/89983
## Unit Test Notes
- The existing `showTextInput_textInputTypeNone()` stays green after
update.
- `inputConnection_textInputTypeNone()` updated to `assertNotNull`. I
would make this more specific, but this is my first venture into the
Flutter engine and don't know enough about those connection attributes.
## Demo
Video below with Zebra MC9300 device. This issue can also be reproduced
in a standard android emulator. Simply add a `TextField`, configure
`keyboardType` to be `TextInputType.none` and attempt to enter text
after running and giving focus to textfield.
Before
https://github.com/flutter/engine/assets/1988098/348ca061-b8b9-4483-956e-0732c1238207
After
https://github.com/flutter/engine/assets/1988098/b65c7251-59b4-4c73-9b85-7ac03f47a7e4
## 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.
- [ ] 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.
# Original pull request description
This introduces the `egl::Surface` and `egl::WindowSurface` types to abstract a raw `EGLSurface`. This also removes some - but not all - EGL surface logic out from `EGLManager`.
Subsequent pull requests will be necessary to:
1. Move ownership of the `egl::WindowSurface` from `egl::Manager` to `FlutterWindowsView`
2. Refactor external texture's off-screen EGL surface to use `egl::Surface`
Part of https://github.com/flutter/flutter/issues/141996
# Reland
https://github.com/flutter/engine/pull/49983 was reverted as it introduced a crash if the render surface fails to be created even though EGL was initialized successfully.
This pull request is split into the following commits:
1. c0b11be79f is the original pull request unchanged
2. 1dc7813845 is the fix: it checks a surface is valid before using it. This also adds several tests to prevent this kind of regression.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The size the engine recieves from the `AndroidSurfaceVulkanImpeller::OnScreenSurfaceResize` appears to be correct in the case of window rotation. Use this instead of physical surface properties to set the swapchain image size.
Querying the physical surface properties seems to have some additional non-deterministic delay. This means that querying the properties during a window rotation will frequently return old values.
Fixes https://github.com/flutter/flutter/issues/138780
Fixes https://github.com/flutter/flutter/issues/132708
This change implements a BundledTestRunner to run most of the tests in testing/fuchsia/test_suites.yaml as ExecutableTestRunner.
- Tests with packages out of out/fuchsia_*_x64/ are ignored for now.
- Tests with extra test command line parameters are ignored for now.
The BundledTestRunner can share most of the logic in ExecutableTestRunner and avoid reinventing the wheel.
This change also fixes the build break of fuchsia_tests in fuchsia_release_x64 which allows tests to run on the build as well.
- Tests not built with AOT are filtered out with variant field in test_suites.yaml.
Bug: https://github.com/flutter/flutter/issues/140179
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Flutter implements the UI isolates message via posting to a UI task queue. That task queue has a primary and a secondary queue. The
* primary is used for running tasks resulated to framework (e.g. draw frame)
* secondary is used to run Dart event loop messages (e.g. received data on a socket)
The Dart semantics requires running microtasks before processing the next event loop message.
The way flutter implements by attaching an observer to the secondary queue. Every time a task from the queue is run, all observers are run and one of them is going to run pending microtasks.
In some situations the engine pauses the dart event loop. The terminology used in the code is "microtask" when in reality what it means is "event loop".
=> This PR changes this terminology to reflect what actually happens.
Reland of: https://github.com/flutter/engine/pull/50139
Metal does not seem to like it when we collect 50+ command buffers at once. Adjust the aiks context logic to regularly flush the cmd buffers.
- use core vm snapshot instead of core-jit, which does not seem to support sound null safety agnostic mode
- remove hardcoded `--no-sound-null-safety` flags from native code and ninja args
- add `sound_null_safety` attribute to `flutter_component` in ninja, which propagates to `dart_kernel`
- migrate one integration test to sound null safety, so that there are integration tests in both modes
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Reverts flutter/engine#50139
Initiated by: jonahwilliams
This change reverts the following previous change:
Original Description:
The Impeller Vulkan backend benefits from batching submission to the vk graphics queue. Managing this automatically is non-trivial and adds surprising/fragile thread based behavior, see: https://github.com/flutter/engine/pull/49870
Instead, introduce an impeller::CommandQueue object that command buffers must be submitted to in lieu of CommandBuffer->Submit, which has been made private.
TLDR
old
```c++
buffer->Submit();
```
new
```c++
context.GetQueue()->Submit({buffer});
```
The Metal and GLES implementations internally just call the private CommandBuffer->Submit, though there may be future opportunities to simplify here. The Vulkan implementation is where the meat is.
Aiks takes advantage of this by storing all command buffers on the aiks context while rendering a frame, and then performing one submit in aiks_context render. I don't think this will introduce any thread safety problems, as we don't guarantee much about aiks context - nor do we use it in a multithreaded context as far as I know.
Other tasks such as image upload still just directly submit their command buffers via the queue.
Fixes https://github.com/flutter/flutter/issues/141123
The Impeller Vulkan backend benefits from batching submission to the vk graphics queue. Managing this automatically is non-trivial and adds surprising/fragile thread based behavior, see: https://github.com/flutter/engine/pull/49870
Instead, introduce an impeller::CommandQueue object that command buffers must be submitted to in lieu of CommandBuffer->Submit, which has been made private.
TLDR
old
```c++
buffer->Submit();
```
new
```c++
context.GetQueue()->Submit({buffer});
```
The Metal and GLES implementations internally just call the private CommandBuffer->Submit, though there may be future opportunities to simplify here. The Vulkan implementation is where the meat is.
Aiks takes advantage of this by storing all command buffers on the aiks context while rendering a frame, and then performing one submit in aiks_context render. I don't think this will introduce any thread safety problems, as we don't guarantee much about aiks context - nor do we use it in a multithreaded context as far as I know.
Other tasks such as image upload still just directly submit their command buffers via the queue.
Fixes https://github.com/flutter/flutter/issues/141123
This change migrates off of the old fuchsia logging apis to use the
structured logging apis. The initial FIDL connection is made during
global initialization (before main()) and the initial minimum log level
is queried from the system. Later on, once the main loop is initialized,
we setup an async task to listen for additional log interest changes
from the system. The advantage of doing this on the main loop is that we
avoid spawning an additional background thread in the process (the
legacy logging apis use the background thread approach).
One added benefit of this change is it reduces the size of the
dart/flutter runner far packages by about 250kb in release mode, because
libsyslog.so and libbackend_fuchsia_globals.so are no longer needed.
flutter/flutter#141924
## 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.
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
The FML_VLOG() macros are designed to use a positive integers, since
they pass -severity to the LogMessage constructor. The negative severity
can also cause some surprising behavior with log filtering. This change
update usages of FML_VLOG(-1) to FML_VLOG(1).
flutter/flutter#141924
- ImageReaderSurfaceProducer no longer drops frames when the producer and the consumers are up to two frames out of sync.
- Have the native C++ side of the Android external textures check if a new frame has been pushed and that the texture needs to be updated. This avoids having to schedule a task on the raster thread for each updated texture.
- Notify the engine earlier that a frame is needed when updating a TLHC texture.
- Re-land fix: Don't close the last dequeued from image reader until the dequeued image is no longer used.
Reverts flutter/engine#50028
Initiated by: jonahwilliams
This change reverts the following previous change:
Original Description:
Once a hardware buffer has been imported (a VkImage created for it), we don't ever need to re-create a VkImage, even when the contents change. The same hardware buffer can be identified by ID. Part of https://github.com/flutter/flutter/issues/142153
Otherwise we spend a lot of time re-creating VkImages:
Draft is here, but is currently leaky: https://github.com/flutter/engine/pull/50028
We only need something like a LRU with the max image size (seems to be 3 for me). This does log locally that I'm not calling close correctly:
```
E/flutter ( 5580): [ERROR:flutter/shell/platform/android/image_external_texture_vk.cc(51)] Size: 3
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
```
FYI @johnmccutchan
Once a hardware buffer has been imported (a VkImage created for it), we don't ever need to re-create a VkImage, even when the contents change. The same hardware buffer can be identified by ID. Part of https://github.com/flutter/flutter/issues/142153
Otherwise we spend a lot of time re-creating VkImages:
Draft is here, but is currently leaky: https://github.com/flutter/engine/pull/50028
We only need something like a LRU with the max image size (seems to be 3 for me). This does log locally that I'm not calling close correctly:
```
E/flutter ( 5580): [ERROR:flutter/shell/platform/android/image_external_texture_vk.cc(51)] Size: 3
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
```
FYI @johnmccutchan
Generated by https://github.com/flutter/engine/pull/48903 (`dart ./tools/header_guard_check/bin/main.dart --fix`).
As discussed with @cbracken and @jmagman, the guards are not technically needed on the Mac/iOS code, but they (a) do not hurt and (b) still provide value if for some reason `#include` is used instead of `#import` (though I suspect we could try to add that to the tool in the future as well).
Fixes https://github.com/flutter/flutter/issues/141571
Shell::Screenshot was impelemnted in a Skia-only way and would crash when invoked. Adds test coverage for the breaking path on iOS that ends up calling `FlutterView drawLayer`.
- ImageReaderSurfaceProducer no longer drops frames when the producer
and the consumers are up to two frames out of sync.
- Have the native C++ side of the Android external textures check if a
new frame has been pushed and that the texture needs to be updated. This
avoids having to schedule a task on the raster thread for each updated
texture.
- Notify the engine earlier that a frame is needed when updating a TLHC
texture.
- Reland fix: Call SurfaceTextureExternalTexture::ProcessFrame if
dl_image_ is null.
Reverts flutter/engine#50033
Initiated by: zanderso
This change reverts the following previous change:
Original Description:
- ImageReaderSurfaceProducer no longer drops frames when the producer and the consumers are up to two frames out of sync.
- Have the native C++ side of the Android external textures check if a new frame has been pushed and that the texture needs to be updated. This avoids having to schedule a task on the raster thread for each updated texture.
- Notify the engine earlier that a frame is needed when updating a TLHC texture.
The AppKit state machine was not well understood before. Sometimes the engine would leave orphan PanZoomStart after a certain sequences including NSEventPhaseMayBegin
Now track each gesture's specific phase instead of boolean true/false which doesn't really accurately represent the system state.
Fixes https://github.com/flutter/flutter/issues/140730
FIxes https://github.com/flutter/flutter/issues/136622
- ImageReaderSurfaceProducer no longer drops frames when the producer
and the consumers are up to two frames out of sync.
- Have the native C++ side of the Android external textures check if a
new frame has been pushed and that the texture needs to be updated. This
avoids having to schedule a task on the raster thread for each updated
texture.
- Notify the engine earlier that a frame is needed when updating a TLHC
texture.
The Impeller context requires us to call Shutdown to ensure that all of its spawned worker threads are joined, ensuring that the raster thread retains the last reference. Without this, we may either destroy parts of the context to early, or attempt to join into a worker thread which will fail.
closesflutter/flutter#53107
This PR introduces support for `AppLifecycleState` on Web, aligning the web's lifecycle events with those of the mobile platforms. This ensures a more consistent developer experience and better lifecycle management across all platforms.
**PR includes:**
- Page Visibility Handling: Integrated the `visibilitychange` DOM event to determine if the app is in a `resumed` or `paused` state based on the visibility state of the document.
- Page Transition Handling: Used `beforeunload` events to better manage the `detached` state.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
On Windows, when using a `MouseRegion` widget to change the cursor it is not actually updated until the cursor is moved. This is because the Windows embedder only updates the `current_cursor_` field but does not actually set the cursor until the window receives the `WM_SETCURSOR` message when the mouse moves. This change makes it set the cursor immediately.
Fixesflutter/flutter#76622
This introduces the `egl::Surface` and `egl::WindowSurface` types to abstract a raw `EGLSurface`. This also removes some - but not all - EGL surface logic out from `EGLManager`.
Subsequent pull requests will be necessary to:
1. Move ownership of the `egl::WindowSurface` from `egl::Manager` to `FlutterWindowsView`
2. Refactor external texture's off-screen EGL surface to use `egl::Surface`
Part of https://github.com/flutter/flutter/issues/141996
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
