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.
Depends on https://github.com/flutter/engine/pull/49828.
No semantic change.
Also adds/documents stencil configurations that are needed for StC. Operations for the current stencil stack are labeled as "legacy".
These interfaces were added to allow experimentation with the AiksLayer in the framework. Since our current approach is focused on aligning display list and impeller, we don't need these anymore.
# 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
- Add depth settings to pipeline variant hash.
- Assign new clip depth to all entities.
- Punt the final depth to all the vertex shaders.
- Add validations to assert all clip depths are resolved.
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
Reported by @loic-sharma.
The tl;dr is it should be OK to have `\r\n` (CRLF) endings if the header
guard is otherwise correct.
This minor refactor (and test) discounts the existence of `\r` when
determining the name of a header guard, i.e.:
```h
#ifndef FLUTTER_MATAN_WHY_H_
```
... is now (correctly) considered a value of `FLUTTER_MATAN_WHY_H_` not
`FLUTTER_MATAN_WHY_H_\r`.
This PR adds a view ID parameter to the Dart FFI `_render` function, and
also remove the logic that skips illegal renders that violates the
render rule.
I decided to implement the change to add the view ID as a separate PR
because it's blocking us from performing benchmark testing internally,
which is required to verify before merging the full multiview pipeline.
We're also abolishing the render rule for now to allow presenting the
warmup frame, which affects the startup performance. It is planned to
implement the render rule once we can coordinate the warmup frame into
the pipeline.
### More on removing the render rule enforcement
The project needs to be divided into two phases:
* Phase 1: Dart:ui doesn't kip out-of-vsync frames. And the pipeline
presents these frames in a hacky way.
* Phase 2: Dart:ui skip out-of-vsync frames, but submit warmup frames
using a dedicated method. The pipeline contains no hacks.
The current logic only enforces the render rule in debug mode. It's not
desired to have the debug mode and the release mode behaving
differently. Moreover, I'd like to make only the necessary changes for
phase 1, so that there is as little "to be used in the future" code
between the two phases as possible.
## Pre-launch Checklist
- [ ] 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] and the [C++,
Objective-C, Java style guides].
- [ ] 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 `///`).
- [ ] I signed the [CLA].
- [ ] 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
* Subpasses are not exposed in the HAL and the need for subpasses in Vulkan can
be determined based on the presence and use of input-attachments in the
shaders. This information is already reflected by the compiler. Because of
this, all references to subpasses have been removed from APIs above the HAL.
* `RenderPassBuilderVK` is a lightweight object used to generate render passes
to use either with the pipelines (compat, base, or per-subpass) or during
rendering along with the framebuffer. Using the builder also sets up the
right subpass dependencies. As long as the builder contains compatible
attachments and subpass counts, different subpasses stamped by the builder
(via the `Build` method) are guaranteed to be compatible per the rules in the
spec.
* Pass attachments are now in the `eGeneral` layout. There was no observable
difference in performance when manually inserting the right transitions.
Except, a lot of transitions needed to be inserted. If we need it, we can add
it back in short order. I wouldn't be averse to adding it if reviewers
insist.
* Additional pipeline state objects need not be created as the sub-pass
self-dependencies are sufficient to setup the render-pass.
* Speaking of the `rasterization_order_attachment_access` extension, its use has
been removed in this patch. I am prototyping adding it back to measure the
overhead introduced by manual subpass management. If the overhead is
measurable, we can use the extension on devices that have it as an added
optimization.
* The complexity of command encoding remains linear (to the number of commands)
per pass.
* This patch only works on a single color attachment being used as an input
attachment. While this is sufficient for current use cases, the Metal
implementation is significantly more capable since the multiple attachments
and attachment types (depth) are already supported. Rounding out support for
this is in progress.
This fixes an issue when the same message was sent to the screen reader
again and was not subsequently announced by VoiceOver despite the prior
message having long been removed from the DOM.
Fixes https://github.com/flutter/flutter/issues/142250
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
