We need to apply the paragraph style's height to the initial default text style on the stack. I also added a `toString` method for `StrutStyle` so that things are a bit easier to debug.
The Linux embedder is rendering to a FlutterOpenGLFramebuffer that specifies an OpenGL FBO. This API allows the embedder to create a color attachment that wraps the FBO so that the render pass will bind to that FBO during encoding.
I am guessing this just either served it's purpose (https://github.com/flutter/flutter/issues/26654, https://github.com/flutter/flutter/issues/26728) or didn't and was never followed up. I can't find any examples of it running on CI - I suspect if we want a test like this, we're better off just adding it to `scenario_app` versus creating more 1-off Android integration test environments.
All dependencies of VK_ANDROID_external_memory_android_hardware_buffer were enabled earlier. But I didn't realize that those extensions became core in Vulkan 1.1. There is no need to load them unnecessarily. It just makes the extensions requirements look more complicated than they are.
Just deletes code. No change in functionality.
An app may render offscreen images before it gets a window. The ContextVK needs to have a default color format so that render passes can be created before the ContextVK is updated to use the window's format.
Work towards https://github.com/flutter/flutter/issues/145988.
Should be a NO-OP in behavior, but hopefully make some of the false negatives less confusing (i.e. getting "missing X outputted files when the test is about to fail anyway".
Part 1 of https://github.com/flutter/flutter/issues/145263
This PR updates the names of builds outside of `local_engine.json` to be
prefixed with the string `ci/` (or `ci\` on Windows). For better or
worse, the "name" field of a build is used to construct a path used as
the source directory of a copy operation (I think the CAS archive
step?). Because of that, changing the name of a build also requires
updating the build output directory of the ninja build.
This PR also adds tests to make sure the naming of these builds remains
consistent.
This fixes the `WindowsTest.EngineCanTransitionToHeadless` flakiness reported by @matanlurey.
EGL surfaces can only be used by a single thread at a time. Concurrent operations are unsafe.
Previously, the EGL surface was destroyed on the platform thread. This was safe as this always happened after the engine was shutdown and the raster thread was stopped. However, in a multi-view world a view can be destroyed while the engine is running. There may be pending raster tasks that operate on the render surface. Thus, the EGL surfaces should be destroyed on the raster thread when it is available.
This bug was introduced by https://github.com/flutter/engine/pull/51681
Part of https://github.com/flutter/flutter/issues/142845
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Further work towards https://github.com/flutter/flutter/issues/141641.
I could imagine making things `presubmit: false` if we think it's not
worth the presubmit capacity.
Removed `:copy_dart_sdk` which seems (a) not to work and (b) not needed
to use the pre-builts.
Closes https://github.com/flutter/flutter/issues/145957.
As @jonahwilliams and @johnmccutchan and I discussed (https://github.com/flutter/flutter/issues/144407), the functionality that was being tested was actually _Android's_ ability to rotate and crop `SurfaceTexture`-backed textures. This same functionality doesn't even exist in the `ImageReader`-based textures (read: modern Android devices):
> Due to an oversight by Android, ImageReader backed surfaces do not respect metadata applied to the surface (rotation & crop). Rotation information is not available at all and crop information is corrupted by the ImageReader (only the width/height is propagated the origin offset is not).
We might decide to re-add this functionality in the Dart `Texture` widget, but given we'll be migrating our plugins to `SurfaceProducer` (again, read: using `ImageTexture` for most Android phones), it's pointless to test this (and isn't even testing Flutter's code).
This reduces our test suite significantly (8 tests down to 2), which should also help with runtime and flakiness.
/cc @zanderso who I'm sure will be stoked.
Work towards https://github.com/flutter/flutter/issues/133569.
This PR is a proof of concept that shows we're able to use `package:test` in `flutter/engine` instead of `package:litetest`.
I think it also shows that, if we're going to continue to vend dependencies this way, we might want to re-think our strategy in terms of using `pub` as a management tool - it's quite unwieldy already. For example, here is every `pubspec.yaml` file in the repo:
```sh
$ find . -name 'pubspec.yaml' -exec sh -c 'echo "$0 $(wc -l < "$0")"' {} \;
# Some files omitted in third_party or similar.
./impeller/tessellator/dart/pubspec.yaml 11
./tools/const_finder/pubspec.yaml 35
./tools/api_check/pubspec.yaml 90
./tools/build_bucket_golden_scraper/pubspec.yaml 47
./tools/licenses/pubspec.yaml 53
./tools/path_ops/dart/pubspec.yaml 26
./tools/engine_tool/pubspec.yaml 76
./tools/dir_contents_diff/pubspec.yaml 19
./tools/compare_goldens/pubspec.yaml 3
./tools/golden_tests_harvester/pubspec.yaml 55
./tools/gen_web_locale_keymap/pubspec.yaml 37
./tools/githooks/pubspec.yaml 63
./tools/android_lint/pubspec.yaml 35
./tools/clang_tidy/pubspec.yaml 76
./tools/pkg/engine_repo_tools/pubspec.yaml 41
./tools/pkg/process_fakes/pubspec.yaml 36
./tools/pkg/engine_build_configs/pubspec.yaml 73
./tools/pkg/git_repo_tools/pubspec.yaml 60
./tools/header_guard_check/pubspec.yaml 70
./sky/packages/sky_engine/pubspec.yaml 8
./shell/vmservice/pubspec.yaml 8
./ci/pubspec.yaml 57
./testing/benchmark/pubspec.yaml 77
./testing/skia_gold_client/pubspec.yaml 66
./testing/pkg_test_demo/pubspec.yaml 116
./testing/smoke_test_failure/pubspec.yaml 31
./testing/dart/pubspec.yaml 71
./testing/android_background_image/pubspec.yaml 22
./testing/litetest/pubspec.yaml 33
./testing/symbols/pubspec.yaml 24
./testing/scenario_app/pubspec.yaml 67
./web_sdk/web_engine_tester/pubspec.yaml 14
./web_sdk/web_test_utils/pubspec.yaml 22
./web_sdk/pubspec.yaml 60
./lib/snapshot/pubspec.yaml 8
./lib/gpu/pubspec.yaml 14
./lib/web_ui/pubspec.yaml 60
./flutter_frontend_server/pubspec.yaml 39
```
I'll file a follow-up issue to discuss pub-package management in the engine.
Work towards https://github.com/flutter/flutter/issues/144835.
Doc (_sorry, internal only_): [go/flutter-engine-goldens-workflow](http://goto.google.com/flutter-engine-goldens-workflow).
This implements the majority of the proposed workflow, that is, optionally having a plain-text version at the root of the directory, and using it to apply a unique suffix we can review in release branches. As it stands, this is a NO-OP outside of tests (it will have no impact, and can be ignored).
What's missing before using this feature in release branches:
- Optimization work with the infra team (not sure if blocking or not):
https://github.com/flutter/flutter/issues/145842
- A dry-run of this with the release team to make sure it works as intended
@gaaclarke As implemented, I _think_ we don't need anything special for [`dir_contents_diff`](286169bb52/tools/dir_contents_diff), but maybe I'm wrong - I think only the _test_ names are being changed, not the names on disk.
/cc @zanderso as well.
Uses the mipmap implementation from https://vulkan-tutorial.com/Generating_Mipmaps .
Today we generate all mip levels from mip level 0, which results in lost data. Instead we need to use the previous mip level
This fixes https://github.com/flutter/flutter/issues/141639
Most of this was previously unimplemented. It turns out the reason for the hang described in the github issue was that there was a typo in the name of the `getMiterLimit` C function, so if the client actually called that method the Wasm module failed to compile, as it couldn't find an import with the misspelled name.
Previously the keyboard was initialized after the view is created. This used to be necessary as the keyboard & text input plugins were strongly tied to a view (and would crash in headless modes). This is no longer necessary, and the keyboard can now be initialized normally as part of the engine initialization.
Part of https://github.com/flutter/flutter/issues/142845
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Currently destroying a view also shuts down the engine. This makes sense as in single-view world where the view also always owns the engine. However, in a multi-view world the views will share the engine. Destroying one view shouldn't necessarily shut down the engine unless that view owns the engine.
Part of https://github.com/flutter/flutter/issues/142845
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This PR groups per-view information in `FlutterCompositor` into a private class, `ViewPresenter`. This makes it easier to manage per-view data and write view operations.
Part of https://github.com/flutter/flutter/issues/145874.
Currently, view presenters are never removed once created, since the macOS runner doesn't support removing views. This will be added in the future.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
