We don't intend to make much progress on the Impeller OpenGLES backend in 2024. I won't remove the capability to run these tests locally (the plumbing is already done and doesn't cost anything), but we don't need to have these just sit/flake on CI consuming resources.
Partial work towards https://github.com/flutter/flutter/issues/144064.
Reland https://github.com/flutter/engine/pull/51698.
This reverts commit 7922740184.
Attempts to improve https://github.com/flutter/flutter/issues/145274.
Our new clipping technique paints walls on the depth buffer "in front" of the Entities that will be affected by said clips. So when an intersect clip is drawn (the common case), the clip will cover the whole framebuffer.
Depth is divvied up such that deeper clips get drawn _behind_ shallower clips, and so many clips actually don't end up drawing depth across the whole framebuffer. However, if the app does a lot of transitioning from a huge clips to a small clips, a lot of unnecessary depth churn occurs (very common in Flutter -- this happens with both the app bar and floating action button in the counter template, for example).
Since progressively deeper layers in the clip coverage stack always subset their parent layers, we can reduce waste for small intersect clips by setting the scissor to the clip coverage rect instead of drawing the clip to the whole screen.
Note that this change _does not_ help much with huge/fullscreen clips.
Also, we could potentially improve this further by computing much stricter bounds. Rather than just using clip coverage for the scissor, we could intersect it with the union of all draws affected by the clip at the cost of a bit more CPU churn per draw. I don't think that's enough juice for the squeeze though.
Before (`Play/AiksTest.CanRenderNestedClips/Metal`):
https://github.com/flutter/engine/assets/919017/7858400f-793a-4f7b-a0e4-fa3581198beb
After (`Play/AiksTest.CanRenderNestedClips/Metal`):
https://github.com/flutter/engine/assets/919017/b2f7c96d-a820-454d-91df-f5fae4976e91
Support for Android's predictive back feature on internal Flutter routes. Reports predictive back gestures to the framework (where supported by the system).
Fixes https://github.com/flutter/flutter/issues/145823
If we try to render a solid filled empty size path, the subpath division code creates an obscene number of vertices that hits overflow errors. Just No-op instead.
We have been transitioning the depth/stencil atttachment to general, even though it can just be in attachment optimal (we never use it as an input attachment).
Reverts: flutter/engine#51698
Initiated by: bdero
Reason for reverting: Golden breakage on framework tree -- https://flutter-gold.skia.org/search?issue=145855&crs=github&patchsets=4&corpus=flutter
Original PR Author: bdero
Reviewed By: {jonahwilliams}
This change reverts the following previous change:
Attempts to improve https://github.com/flutter/flutter/issues/145274.
Our new clipping technique paints walls on the depth buffer "in front" of the Entities that will be affected by said clips. So when an intersect clip is drawn (the common case), the clip will cover the whole framebuffer.
Depth is divvied up such that deeper clips get drawn _behind_ shallower clips, and so many clips actually don't end up drawing depth across the whole framebuffer. However, if the app does a lot of transitioning from a huge clips to a small clips, a lot of unnecessary depth churn occurs (very common in Flutter -- this happens with both the app bar and floating action button in the counter template, for example).
Since progressively deeper layers in the clip coverage stack always subset their parent layers, we can reduce waste for small intersect clips by setting the scissor to the clip coverage rect instead of drawing the clip to the whole screen.
Note that this change _does not_ help much with huge/fullscreen clips.
Also, we could potentially improve this further by computing much stricter bounds. Rather than just using clip coverage for the scissor, we could intersect it with the union of all draws affected by the clip at the cost of a bit more CPU churn per draw. I don't think that's enough juice for the squeeze though.
Before (`Play/AiksTest.CanRenderNestedClips/Metal`):
https://github.com/flutter/engine/assets/919017/7858400f-793a-4f7b-a0e4-fa3581198beb
After (`Play/AiksTest.CanRenderNestedClips/Metal`):
https://github.com/flutter/engine/assets/919017/b2f7c96d-a820-454d-91df-f5fae4976e91
Instead of just returning, if our paragraph builder has empty text, we still need to generate a set of line breaks for skia to use. Otherwise, it will actually cause subtle memory access errors.
Reverts: flutter/engine#51685
Initiated by: matanlurey
Reason for reverting: goldctl does not disambiguate negatives from untriaged images (see 9b9adad080/gold-client/cmd/goldctl/cmd_imgtest_test.go (L325)).
Original PR Author: matanlurey
Reviewed By: {mdebbar, gaaclarke}
This change reverts the following previous change:
`flutter/engine`-side fix for https://github.com/flutter/flutter/issues/145043.
- Before this PR, if a negative image was encountered, we'd silently pass pre-submit, merge, and turn the tree red.
- After this PR, a negative image both makes pre and post-submit red.
Added tests, and fixed up some unrelated tests that were accidentally setting `pid` instead of `exitCode`. Oops!
/cc @zanderso and @eyebrowsoffire (current engine sheriff).
Attempts to improve https://github.com/flutter/flutter/issues/145274.
Our new clipping technique paints walls on the depth buffer "in front" of the Entities that will be affected by said clips. So when an intersect clip is drawn (the common case), the clip will cover the whole framebuffer.
Depth is divvied up such that deeper clips get drawn _behind_ shallower clips, and so many clips actually don't end up drawing depth across the whole framebuffer. However, if the app does a lot of transitioning from a huge clips to a small clips, a lot of unnecessary depth churn occurs (very common in Flutter -- this happens with both the app bar and floating action button in the counter template, for example).
Since progressively deeper layers in the clip coverage stack always subset their parent layers, we can reduce waste for small intersect clips by setting the scissor to the clip coverage rect instead of drawing the clip to the whole screen.
Note that this change _does not_ help much with huge/fullscreen clips.
Also, we could potentially improve this further by computing much stricter bounds. Rather than just using clip coverage for the scissor, we could intersect it with the union of all draws affected by the clip at the cost of a bit more CPU churn per draw. I don't think that's enough juice for the squeeze though.
Before (`Play/AiksTest.CanRenderNestedClips/Metal`):
https://github.com/flutter/engine/assets/919017/7858400f-793a-4f7b-a0e4-fa3581198beb
After (`Play/AiksTest.CanRenderNestedClips/Metal`):
https://github.com/flutter/engine/assets/919017/b2f7c96d-a820-454d-91df-f5fae4976e91
Resolves https://github.com/flutter/flutter/issues/144333. (Specifically, this [follow-up issue](https://github.com/flutter/flutter/issues/144333#issuecomment-2002399870))
When drawing objects with a perspective transform, the rasterizer applies perspective correction for interpolated vertex attributes. By absorbing W and replacing Z with a discrete value, we were essentially removing all perspective information and disabling perspective correction.
Instead, we can manipulate the Entity transform to remap the output Z range to fit within the small depth slices that each Entity is allotted.
The golden draws a clip sandwich:
1. Draw and restore a difference clip _before_ drawing the airplane image. This clip will get drawn to the depth buffer behind the airplane image.
2. Draw an oval clip that applies to the airplane image. This clip will get drawn in front of the airplane image on the depth buffer.
3. Draw the airplane image with a 3D rotation and perspective transform.
4. Draw a semi-translucent blue circle atop all previous draws.
Before:
https://github.com/flutter/engine/assets/919017/c2a7d012-714e-4234-83ac-61c792172f30
After:
https://github.com/flutter/engine/assets/919017/de3b78ff-00bf-4bc9-8821-8e86b9a9e6bf
`flutter/engine`-side fix for https://github.com/flutter/flutter/issues/145043.
- Before this PR, if a negative image was encountered, we'd silently pass pre-submit, merge, and turn the tree red.
- After this PR, a negative image both makes pre and post-submit red.
Added tests, and fixed up some unrelated tests that were accidentally setting `pid` instead of `exitCode`. Oops!
/cc @zanderso and @eyebrowsoffire (current engine sheriff).
The previous PR https://github.com/flutter/flutter/issues/143420 rounds out the layers and rounds in the platform views. This results in missing pixel on the edge of the intersection when there's fractional coordinate (as shown in the screenshot below), because platform view is below the layers.
It turns out that we have to round out both platform view and layers, because:
- rounding in platform view rects will result in missing pixels on the edge of the intersection.
- rounding in layer rects will result in missing pixels on the edge of the layer that's on top of the platform view.
This PR simply skips the single (or partial) pixel on the edge, which is a special case, while still preserve the `roundOut` behavior for general non-edge cases.
Before the fix, notice a very thin gray line cutting through the purple box:
<img src="https://github.com/flutter/engine/assets/41930132/1482d81a-337e-4841-ac08-eff08bbc71ef" height="500">
Then after the fix, the gray line is gone:
<img src="https://github.com/flutter/engine/assets/41930132/0eddae69-ab62-4de6-8932-c67cc5aced73" height="500">
*List which issues are fixed by this PR. You must list at least one issue.*
https://github.com/flutter/flutter/issues/143420
*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
No semantic changes, just consolidates static functions in FlutterViewController.mm local to the translation unit into a single contiguous block at the top.
Also includes three minor (non-semantic) changes:
* Corrects static function naming to UpperCamelCase
* Adds doc comments for `OnKeyboardLayoutChanged`
* Adds a mark to help highlight the static data/function block at the top of the file in Xcode.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This doesn't actually seem to be helping. For the most part, the frame time of the banners is steady with occassional spikes. Adding the framerate cap doesn't help the spikes, since those are in the 30+ ms frame time, and just results in everything else looking janky as well (especially if we dance around the cap, then we go 120 - 80)
Since this is based on an arbitrary number, from an arbitrary app, on an arbitrary point in time we should remove it and instead try to fix the performance problems
The DisplayListBuilder only updates the paint attributes that are relevant to a given operation. DrawPaint does not support mask filters, so DisplayListBuilder::DrawPaint will not modify the mask filter state. So a call to DrawPaint in the display list dispatcher may receive a paint containing a mask filter set by a previous call.
Aiks Canvas::DrawPaint should ignore any mask filter set on the paint (matching the spec for Skia's SkCanvas::drawPaint)
Fixes https://github.com/flutter/flutter/issues/145442
Fixes https://github.com/flutter/flutter/issues/144109
The Foreground blend optimization attempts to combine what would be a composited operation directly into the parent pass. Unfortunately, this doesn't work if the entity has a non scale/translate transform. Since we don't actually know the entities geometry, we've been using the coverage rect - but the coverage rect is always an axis aligned rectangle. So we can't use it to determine the actual geometry.
The clip coverage tracking has had some bugs, but its been difficult to test as it was mixed into the regular entity pass workflow. This change pulls this logic and the clip recorder logic into a new class that is responsible for managing the coverage stacks.
Adds an unbalanced restore unit test as well.
