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
Reverts flutter/engine#50161
Initiated by: jonahwilliams
Reason for reverting: This is causing what looks like bogus goldens on the framework -> engine roll: https://github.com/flutter/flutter/pull/142966
Original PR Author: ditman
Reviewed By: {yjbanov, mdebbar}
This change reverts the following previous change:
Original Description:
The Scene of the HTML renderer is passing incorrect size information to the engine, and when DPR<1, it can result in elements being culled off of the viewport.
In addition to that, when an app is embedded, not all changes in DPR cause a Resize event (only those some of the dimensions fails by a rounding error!), so this PR ensures that all DPR events in embedded trigger a resize event.
### Issues
Fixes https://github.com/flutter/flutter/issues/129182
### Testing
Looking good at: https://dit-astral-test.web.app
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
I expect `Linux linux_android_emulator_tests` and `Linux
linux_android_emulator_tests_api_33` to fail.
When they fail, I'll fix the assertion
(https://github.com/flutter/flutter/issues/142746) before merging this
PR.
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.
Cache vk::RenderPass and vk::Framebuffer objects on the resolve texture of any render target attachments. Use these on the next frame unconditionally.
Fixes https://github.com/flutter/flutter/issues/141750
The Scene of the HTML renderer is passing incorrect size information to the engine, and when DPR<1, it can result in elements being culled off of the viewport.
In addition to that, when an app is embedded, not all changes in DPR cause a Resize event (only those some of the dimensions fails by a rounding error!), so this PR ensures that all DPR events in embedded trigger a resize event.
### Issues
Fixes https://github.com/flutter/flutter/issues/129182
### Testing
Looking good at: https://dit-astral-test.web.app
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Fixes https://github.com/flutter/flutter/issues/141351 (speculatively - I have not directly reproduced this in an application, but without this change the added test crashes with a segfault in the submit callback).
If the rasterizer gets torn down, the surface gets released and the submit callback may fire on a collected object. Capturing `this` isn't safe. I'm not quite sure how that could happen from the linked stack trace though, since the draw call and the teardown call should be happening on the raster thread, and if the surface was reset then the draw call should've failed earlier...
The added test causes a segfault without the change.
This regression was introduced in 0682efb50f which made it so that the updated surface size would be provided to the swapchain impl out-of-band instead of being inferred from the surface properties (to avoid a lag between the reports of the two).
However, the playgrounds used the window size to report the updated size. This is fine where the window scale is 1. But fails on high-dpi devices. The patch replaces the call to get the window size with an equivalent call to get the framebuffer size.
The failure was a blown stack due to a new swapchain impl being created over and over again because the size was always out of date.
Fixes https://github.com/flutter/flutter/issues/142833
fixes https://github.com/flutter/flutter/issues/142753
The theory here is that once you start throwing away more than 15/16th of the signal it's pretty noticable. By looking at the blur under different circumstances that seems like a reasonable limit.
There is no automated test for this. Doing so would be quite involved and would involve evaluating multiple rendered frames. There is a manual test.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Specifying the `--use_swiftshader` flag will find an setup the SwiftShader ICD in the process. Allows switching between two Vulkan implementation (system and SwiftShader) quickly using a flag.
Following up on https://github.com/flutter/flutter/issues/127070
*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
## 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.
The number of arguments are not used.
And also, even if we need it in the future, they can be derived at compile time:
```cpp
template <typename T>
struct function_traits;
template <typename Ret, typename... Args>
struct function_traits<Ret(Args...)>
{
using params = std::tuple<Args...>;
};
template <typename T>
constexpr std::size_t get_parameter_count() {
return std::tuple_size<typename function_traits<T>::params>::value;
}
template <typename T>
struct member_function_traits;
template <typename C, typename Ret, typename... Args>
struct member_function_traits<Ret(C::*)(Args...)>
{
using params = std::tuple<Args...>;
};
template <typename T>
constexpr std::size_t get_member_function_parameter_count() {
return std::tuple_size<typename member_function_traits<T>::params>::value;
}
```
(I got the code above with ChatGPT but I verified that they work)
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Changes to use the proto.textpb config file as the version of the emulator device and show the cipd dependency version in the dependencies so devs know it can be updated.
This will not pass until recipe changes have landed.
*List which issues are fixed by this PR. You must list at least one issue.*
Fixes https://github.com/flutter/flutter/issues/142261
*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 optimization was discovered when reviewing the bounds accumulation code in DisplayListBuilder. There is trivially wasted work in the `Build()` method that can be easily avoided.
When a Builder is preparing an RTree, it accumulates a list of bounds for every rendering op, but doesn't union them up front. If you ask the Builder for the bounds of the accumulated ops, it will have to union all of the rectangles to produce an answer. But, if you ask the Builder to produce an RTree, that process will implicitly combine all of the rectangles as a side effect of creating the tree structure - and that RTree object has a bounds method that can return the result directly.
This change leverages the construction of the RTree to avoid having to union all of the rects twice which can only save time when constructing the majority of DisplayList objects used in a scene.
This define isn't used in a C++ TU. Only the build scripts (in `//flutter/shell/platform/android/BUILD.gn`) use the flag to decide whether to package the validation layers.
Remove the define that no one uses.
