Resolves https://github.com/flutter/flutter/issues/134748.
This was a really fun experiment. I learned a lot from it, and it genuinely helped me solve some coverage-related problems, but the reality is it was too little too late -- by the time we had this capture system, we had already solved most of the problems that would have benefitted from this.
It's been a few months since I've used or extended the capabilities of this capture system for something, and I don't have the spare time/energy to give it the love it needs to realize the vision I had for it. I still almost exclusively use a combination of native frame captures and print debugging to solve problems.
RIP in peace.
I added this feature a long time ago on a rainy afternoon, and @gaaclarke mentioned that it's being removed from the framework anyway. We should just remove this if that's the case.
Workaround for https://github.com/flutter/flutter/issues/136112
If the glyph scale is too large, say in the hundreds or thousands, then glyph itself will likely be too big to fit in the atlas. Instead of failing to render - clamp the scale (not the size, which is bounds * scale) to a much lower scaling parameter.
We only use this for drawPoints, a rarely used API. On local tests, this is just as fast with the CPU backend implementations.
While this was intended to be the first in a series of compute based rendering experiments, it hasn't really been worth the carrying cost. So lets shrink the complexity and and remove another shader to boot.
Fixes https://github.com/flutter/flutter/issues/147184
In order to land https://github.com/flutter/engine/pull/52303 , we need to finally fix the advanced blend draw vertices combo. Right now a ColorFilter is used for advanced blends which doesn't work if there are overlapping vertices.
See also: https://github.com/flutter/flutter/issues/145707
The issue was fixed for drawVertices/drawAtlas pipeline blends using the porterduff shader. This extends this to advanced blends, but since drawVertices/atlas with an advanced blend is uncommon and because we don't 15 new shader variants, just add one special uber shader.
Part of https://github.com/flutter/flutter/issues/131345
Works to prevent future outages like https://github.com/flutter/flutter/issues/147180.
Also added an explicit `--no-skia-gold` flag to use when we don't want Skia Gold used, and used it in the one place we decided (in internal chat) it made sense, `mac_unopt.json` (was added in 674874e613 for validation-layers testing only).
I suspect that the change to clear the surface is the result of the
scenario app instability. just a guess: the screenshots looks like we're
missing the platform view. maybe the clearing of the surface is causing
an extra frame to be pushed. That frame is getting picked up in the
golden due to a race condition that is hard to hit locally
Testing disabling of this functionality in the golden test. If this pass
a real fix involves some sort of hook into the rendering to verify it
has fully completed before screenshotting.
Found that these intermediates added a non-trivial amount of artifacts to the out directory. Folks run our of space because of the size of intermediates sometimes and this just exacerbates that problem.
Reverts: flutter/engine#51229
Initiated by: gmackall
Reason for reverting: blocking engine->framework roll (I missed some framework code referencing the v1 embedding).
Original PR Author: gmackall
Reviewed By: {matanlurey, reidbaker}
This change reverts the following previous change:
Fixes https://github.com/flutter/flutter/issues/143531
Also fixes a random typo I found
~TODO to test this~ (no more todo):
-~test the framework against this as well, probably with a dummy PR changing the engine commit to my branch if this is possible~ not possible, made a best effort removal of framework code in https://github.com/flutter/flutter/pull/144726.
-~figure out if the old embedding is used in g3 at all~ removed all uses
-~figure out exactly what the ShimPluginRegistry/ShimRegistrar are doing, and if fully deleting them was right~ (see https://github.com/flutter/engine/pull/51229#issuecomment-1981757743)
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Finishes part 2 of https://github.com/flutter/flutter/issues/145263.
This required fixing a python script to use the version of Java obtained
through the DEPS file rather than one assumed to exist in the
environment.
Reverted in https://github.com/flutter/engine/pull/51679 due to https://github.com/flutter/flutter/issues/144109
The foreground blend cases where using the coverage rect to determine the resulting position and UVs. this only worked if the CTM was scale translate, in rotation/skew/perspective cases the coverage rect is incorrect for choosing the texture coordinate position. Instead of positioning w/ coverage, use the snapshot transform which includes the scale/translation and correctly applies other transforms.
Reverts: flutter/engine#51921
Initiated by: zanderso
Reason for reverting: This Dart roll is blocking the roll of the engine to the framework. Unblocking the rolls depends on addressing https://github.com/flutter/flutter/issues/146164.
Original PR Author: jason-simmons
Reviewed By: {zanderso, jonahwilliams}
This change reverts the following previous change:
The Dart SDK is now only building an AOT snapshot for the frontend server (see https://dart-review.googlesource.com/c/sdk/+/359100)
Fixes https://github.com/flutter/flutter/issues/145707
Part of https://github.com/flutter/flutter/issues/131345
If we're drawing vertices with per-color, a non-advanced blend, and a texture (with or without coordinates), use the porter duff shader to perform the blend without creating a sub render pass. IN addition to being more performant, this eliminates any potential rendering bugs caused by overlapping vertices.
This is not yet fixed for advanced blends.
Just removing some of the noise of walking through Java files in Android Studio, should be a NO-OP[^1].
- `androidx.test.runner.AndroidJUnit4` -> `androidx.test.ext.junit.runners.AndroidJUnit4`
- `androidx.test.InstrumentationRegistry` -> `androidx.test.platform.app.InstrumentationRegistry`
[^1]: Famous last words.
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.
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.
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.
Relands https://github.com/flutter/engine/pull/51589
The fix is in 74397bc171c74d2bfb24e82b47f2aa29d70c1711. I couldn't
figure out how to get a test in the engine to cover it. The test is in
the devicelab.
Here's what I attempted:
```c++
TEST_P(AiksTest, BlendModePlusAlphaColorFilterAlphaWideGamut) {
if (GetParam() != PlaygroundBackend::kMetal) {
GTEST_SKIP_("This backend doesn't yet support wide gamut.");
}
EXPECT_EQ(GetContext()->GetCapabilities()->GetDefaultColorFormat(),
PixelFormat::kR16G16B16A16Float);
Canvas canvas;
canvas.Scale(GetContentScale());
canvas.DrawPaint({.color = Color(0.1, 0.2, 0.1, 0.5)});
canvas.SaveLayer({
.color_filter = ColorFilter::MakeBlend(BlendMode::kPlus,
Color(Vector4{1, 0, 0, 0.5})),
});
Paint paint;
paint.color = Color(1, 0, 0, 0.5);
canvas.DrawRect(Rect::MakeXYWH(100, 100, 400, 400), paint);
paint.color = Color::White();
canvas.Restore();
ASSERT_TRUE(OpenPlaygroundHere(canvas.EndRecordingAsPicture()));
}
```
## 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
