Due to https://github.com/flutter/flutter/issues/127500 , we can get in a state where enable-impeller is true but we're using Skia. We need to either fall back completely to Skia, make this configuration fatal, or remote the check
----------------
Conversion of SkTextBlobs to impeller::TextFrame objects is one of the most expensive operations in display list dispatching. While the rest of the engine and framework makes a reasonable attempt to cache the SkTextBlobs generated during paragraph construction, the design of the dl dispatcher means that these the Impeller backend will always reconstruct all text frames on each frame - even if the display list/picture that contained those text frames was unchanged.
Removing this overhead is one of the goals of https://github.com/flutter/engine/pull/45386 , however this patch is also fairly risky and will be difficult to land. As a more incremental solution, we can instead construct the impeller::TextFrame objects when performing paragraph painting and record them in the display list. This both moves the text frame construction to the UI thread and allows the framework/engine to cache unchanged text frames.
This also does not conflict with the dl_aiks_canvas patch directly, and is fine to land before or after it does. (though I'd argue we should land this first).
To compare the current performance levels, I ran the complex_layout_scroll perf test, since this is fairly text filled. On a Pixel 6 pro. Across several runs this is a fairly consistent ~1ms raster time improvement.
Fixes https://github.com/flutter/flutter/issues/133204
Closes https://github.com/flutter/flutter/issues/135057.
This is a fair bit more involved than previous changes, just due to the sheer number of implicit conversions.
Highlights:
- Made `public uint32_t argb` `private uint32_t argb_`, and added `argb()` instead.
- Added `ToSk(DlColor)` instead of using implicit conversions.
There were a bunch of places where I had to make a judgement call (particularly in tests) to keep the code a bit "messy", i.e. `DlColor(SK_RED)`, just to make the diff as small as possible and to prevent silly copy and paste bugs. I'd be open to filing a follow-up issue to reduce unnecessary wrapping.
Work towards https://github.com/flutter/flutter/issues/134969.
These are all self-contained, so I bundled them all together.
All fixes are generated by `clang-tidy --fix`, and manual search/replace if that wasn't sufficient.
Reverts flutter/engine#45418
Some google3 tests are hitting the CHECK I added in the DlSkCanvasDispatcher::drawTextFrame, which indicates that the SkParagraph code likely thinks impeller is enabled, whereas other code might be running with Skia.
Perhaps this could happen if its software rendering? It should be a fatal error on startup so we can track this down.
Conversion of SkTextBlobs to impeller::TextFrame objects is one of the most expensive operations in display list dispatching. While the rest of the engine and framework makes a reasonable attempt to cache the SkTextBlobs generated during paragraph construction, the design of the dl dispatcher means that these the Impeller backend will always reconstruct all text frames on each frame - even if the display list/picture that contained those text frames was unchanged.
Removing this overhead is one of the goals of https://github.com/flutter/engine/pull/45386 , however this patch is also fairly risky and will be difficult to land. As a more incremental solution, we can instead construct the impeller::TextFrame objects when performing paragraph painting and record them in the display list. This both moves the text frame construction to the UI thread and allows the framework/engine to cache unchanged text frames.
This also does not conflict with the dl_aiks_canvas patch directly, and is fine to land before or after it does. (though I'd argue we should land this first).
To compare the current performance levels, I ran the complex_layout_scroll perf test, since this is fairly text filled. On a Pixel 6 pro. Across several runs this is a fairly consistent ~1ms raster time improvement.
### Skia
```
"average_frame_build_time_millis": 1.497333333333333,
"90th_percentile_frame_build_time_millis": 2.038,
"99th_percentile_frame_build_time_millis": 17.686,
"worst_frame_build_time_millis": 23.095,
"missed_frame_build_budget_count": 3,
"average_frame_rasterizer_time_millis": 5.5078589743589745,
"stddev_frame_rasterizer_time_millis": 2.226343414420338,
"90th_percentile_frame_rasterizer_time_millis": 7.481,
"99th_percentile_frame_rasterizer_time_millis": 19.11,
"worst_frame_rasterizer_time_millis": 79.799,
"missed_frame_rasterizer_budget_count": 7,
"frame_count": 234,
"frame_rasterizer_count": 234,
"new_gen_gc_count": 10,
"old_gen_gc_count": 2,
```
### Impeller (ToT)
```
"average_frame_build_time_millis": 1.431575000000001,
"90th_percentile_frame_build_time_millis": 2.196,
"99th_percentile_frame_build_time_millis": 14.486,
"worst_frame_build_time_millis": 23.728,
"missed_frame_build_budget_count": 2,
"average_frame_rasterizer_time_millis": 6.536087499999999,
"stddev_frame_rasterizer_time_millis": 1.9902712500000004,
"90th_percentile_frame_rasterizer_time_millis": 9.705,
"99th_percentile_frame_rasterizer_time_millis": 14.727,
"worst_frame_rasterizer_time_millis": 17.838,
"missed_frame_rasterizer_budget_count": 1,
"frame_count": 240,
"frame_rasterizer_count": 240,
"new_gen_gc_count": 10,
"old_gen_gc_count": 2,
```
### Impeller (Patched)
```
"average_frame_build_time_millis": 1.4500167364016743,
"90th_percentile_frame_build_time_millis": 2.478,
"99th_percentile_frame_build_time_millis": 14.883,
"worst_frame_build_time_millis": 18.782,
"missed_frame_build_budget_count": 1,
"average_frame_rasterizer_time_millis": 5.023033333333336,
"stddev_frame_rasterizer_time_millis": 1.6445388888888894,
"90th_percentile_frame_rasterizer_time_millis": 7.814,
"99th_percentile_frame_rasterizer_time_millis": 13.497,
"worst_frame_rasterizer_time_millis": 15.008,
"missed_frame_rasterizer_budget_count": 0,
"frame_count": 239,
"frame_rasterizer_count": 240,
"new_gen_gc_count": 8,
"old_gen_gc_count": 0,
```
Fixes https://github.com/flutter/flutter/issues/133437
With this fix, the [benchmarks](https://github.com/flutter/flutter/pull/133434) for pictures with huge bounds become runnable under more conditions. Currently those benchmarks only run on platforms where we don't run into this issue. The performance on those platforms/conditions will not change much, but with this fix we can run them on Impeller and add a variant that has a platform view on the display.
Relands https://github.com/flutter/engine/pull/45131
Fixes https://github.com/flutter/flutter/issues/132416
Differences from last time:
- Some minor merge conflict fixes
- Use the RTree to get the bounds instead of recalculating the bounds
- Make the iOS platform view controller implementation use the impeller-aware slices instead of the display list ones. This has been fixed for Android and the desktop embedding, but I missed iOS. The unit tests weren't actually running before I branched for my PR, @zanderso fixed them up separately and this resulted in catching the failures on post submit last time.
Closes https://github.com/flutter/flutter/issues/132994.
I suspect this is imperfect, so please suggest any changes or additions (either using GitHub's tooling or as a review comment).
/cc @dnfield
Reverts flutter/engine#45131
This is failing the Impeller variants of the unobstructed platform views tests:
https://ci.chromium.org/ui/p/flutter/builders/prod/Mac%20Production%20Engine%20Drone/132249/overview
```
Failing tests:
-[UnobstructedPlatformViewTests testPlatformViewsMaxOverlays]
-[UnobstructedPlatformViewTests testOneOverlay]
-[UnobstructedPlatformViewTests testOneOverlayPartialIntersection]
-[UnobstructedPlatformViewTests testTwoIntersectingOverlays]
-[UnobstructedPlatformViewTests testOneOverlayAndTwoIntersectingOverlays]
** TEST FAILED **
```
We've retried it a few times so I suspect this isn't a flake.
This is a reland of https://github.com/flutter/engine/pull/44248
Fixes https://github.com/flutter/flutter/issues/132416
Changes from last time:
- The `drawPoints` benchmark was failing to render anything meaningful because of an error in `AiksLayer` that resulted in an infinitely sized bounding rectangle poisoning the bounds with `NaN` (this happens, for example, with a `drawPaint` call, which that benchmark happens to use). Added a test covering this and filed https://github.com/flutter/flutter/issues/132770 to explore ways to avoid this in the future.
- There was a bug in `DlAiksCanvas::SaveLayer` where a `nullptr` `paint` but non-`nullptr` `backdrop` was failing to actually save the layer. This resulted in incorrect rendering.
- There was a bug in `impeller::Canvas::DrawPicture` that resulted in incorrect stencil depth counting. That was fixed separately by @bdero, but was the cause of incorrect rendering in some Wonderous screens.
- I've added a simple implementation for `AiksLayer::IsReplacing`. It does not currently compare as deeply as the `DisplayListLayer` version potentially does, but it is good enough to avoid the regression noted in https://github.com/flutter/flutter/issues/132071. That regression was on a benchmark that greatly benefits from partial repaint. With the new implementation, it still gains partial repaint where it previously did not. There is more work that can be done here, filed https://github.com/flutter/flutter/issues/133361 to track that work.
I merged but did not fully integrate the `DisplayListBuilder`/`CanvasToReceiver` work that @flar has done. I have a local experiment with that, but would prefer to see this land and run through the device lab so we get some better comparison numbers for which one performs better.
Closes https://github.com/flutter/flutter/issues/132860.
- If `setDither(true)` is called, and an existing `setColorSource` is a gradient, it is ignored.
- If `setColorSource(...)` is called, and it is a gradient, and dithering was previously set, it is cleared.
I'm not sure this is fool proof.
DisplayListBuilder grew over time from a class that implemented a developer-unfriendly stateful API into one that implemented both the developer-friendly DlCanvas API as well as its original stateful API. Over time, the stateful API was buried under a "testing only" facade.
In the meantime, the optimization features that it applies to the DlCanvas calls before it records the operations in a DlOp store are useful without the recording process and so I've been wanting to break those into 2 parts for a while with the goal of removing all stateful APIs from DisplayListBuilder (see https://github.com/flutter/flutter/issues/108303).
This PR takes a major step along that direction by splitting DisplayListBuilder into essentially a convenience class that marries 2 new classes together to achieve its old functionality:
- `DlCanvasToReceiver` - a class that implements DlCanvas, optimizes common situations, and then sends commands to any object that implements `DlOpReceiver`
- `DlOpRecorder` - an implementation of DlOpReceiver that records the operations in a buffer from which to create a `DisplayList` object
- `DisplayListBuilder` now inherits from DlCanvasToReceiver to get the optimizations and provides it with an instance of `DlOpRecorder` as the receiver that it will send its results to
- Similarly, a `DlCanvasToReceiver` instance could be directed to an `impeller:DlDispatcher` to achieve a more straight-through path from the DlCanvas interface to impeller Pictures.
In the Impeller backend, we **only** support dithering of _gradients_. In addition, it will be the default (and only option).
In the [process of enabling dithering by default](https://github.com/flutter/engine/pull/44705), i.e.
```diff
class Paint {
- static bool enableDithering = false;
+ static bool enableDithering = true;
}
```
... we realized with internal Google testing this will now apply dithering on more than just gradients, i.e. images in the Skia backend. Since we won't support dithering of images in the Impeller backend, this PR gives a "hint" on whether the `colorSource` (if one is set) can be dithered by the contrived rules we've created.
Fixes https://github.com/flutter/flutter/issues/130141
The primary goal of this patch is to move dispatching of `dart:ui` `Canvas` commands to the UI thread.
Before this patch, the architecture is something like:
## UI Thread
- `dart:ui` talks to `DisplayListBuilder`, a `DlCanvas` implementation.
- `DisplayListBuilder` does some clip/bounds tracking and creates a `DisplayList` object that is held by `dart:ui`'s `Picture` objects.
- `DisplayList`s are added to `DisplayListLayer`s in `flow`.
## Raster Thread
- `flow` flattens the various operations into a single `DisplayList` via another `DisplayListBuilder`.
- A `DlOpReceiver`implementation converts that `DisplayList` into an `Aiks` `Canvas`/`Picture`.
After this patch, the architecture instead looks like:
## UI Thread
- No change for Skia.
- If Impeller, use a new `DlCanvasImplementation` that talks to `Aiks`'s `Canvas`.
- If Impeller, `dart:ui` Picture's now hold an `Aiks` `Picture`, which get shared into `AiksLayer`s in `flow`.
## Raster thread
- No change for Skia, but some light refactoring for places that assumed a `DisplayListBuilder` where they really just needed a `DlCanvas`.
- The `Aiks` `Picture`s are combined using new API on `DlCanvas` and still backed by `Aiks`.
These changes show significant improvement on raster times on Android and only very small regressions on UI times in local testing, see https://gist.github.com/dnfield/26528090194c9f5abdbac13cdcbf4f79 for old gallery transition perf numbers.
Many of the other changes in this patch are related to the following:
- Making `DlRTree` usable for Impeller.
- It would be nice to have a version of DlRTree that speaks `impeller::Rect`.
- Creating the requisite classes to support `EmbeddedViews` so that Desktop works.
This patch does not remove the `impeller::DlDispatcher`, which now would only be used in tests.
When a saveLayer is rendered with an ImageFilter that modifies the bounds of the rendered pixels, and some of the content of that saveLayer did not intersect the clip, but the filtered output of that content did intersect the clip, we might not accumulate the bounds of those rendering operations into the DisplayList bounds.
This bug was not encountered during practical testing, but showed up on some testing with the new NOP culling code.
For now, this bug only affects the accuracy of the reported bounds of the DisplayList, but that can affect raster caching and potentially the layer culling done in the LayerTree. It might also affect the accuracy of the RTree associated with the DisplayList, which would only show up in rare circumstances when the indicated operation was used in the presence of an embedded view.
Fixes https://github.com/flutter/flutter/issues/129862
This reverts commit cd52c0ce82b37bc9d16bea26fbd1753174c49e42.
These changes were exposing an underlying bug in the DisplayListMatrixClipTracker that has now been fixed independently (https://github.com/flutter/engine/pull/43664). There are no changes to the commit being relanded here, it has been tested on the Wondrous app which demonstrated the regression before the NOP culling feature was reverted and it now works fine due to the fix of the underlying cause.
Most of the #include directives for SkPicture are removed except where they are still functional. Many comments rewritten to no longer be SkPicture-centric.
- DL unit tests still use it for consistency testing
- rasterizer/engine still use it for screen shot support
- Fuchsia still uses it extensively
Addresses most of https://github.com/flutter/flutter/issues/128060
Most of the uses of SkPicture and Recorder are removed from the engine sources. The few that remain are:
- DisplayList <-> Skia consistency testing code
- Legacy code only used from Fuchsia
- Dart CanvasKit uses which aren't actually using the local Skia sources or libraries
These are all comment and include file changes and so the testing is in the building.
Reverts flutter/engine#42584. (Thanks to @jonahwilliams for bisecting)
With this change, layers are getting clipped incorrectly when rendering
platform views in Wondrous.
Update flutter engine includes to be more specific about use of Skia includes.
These changes are required to unblock the Skia roller that has new streamlined include files.
Fixes https://github.com/flutter/flutter/issues/128412
Adds
- `DlRegion DlRegion::MakeUnion(const Region &, const DlRegion &)`
- `DlRegion DlRegion::MakeIntersection(const Region &, const DlRegion
&)`
- `bool DlRegion::intersects(const DlRegion &)`
- `bool DlRegion::intersects(const SkIRect &)`
Instead of per span line vector all spans are stored in continuous
buffer.
Complete benchmarks:
```
-----------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
-----------------------------------------------------------------------------------------------
BM_DlRegion_IntersectsSingleRect/Tiny 2688 ns 2687 ns 258580
BM_SkRegion_IntersectsSingleRect/Tiny 85889 ns 85877 ns 8092
BM_DlRegion_IntersectsSingleRect/Small 4814 ns 4813 ns 142874
BM_SkRegion_IntersectsSingleRect/Small 101102 ns 101102 ns 6833
BM_DlRegion_IntersectsSingleRect/Medium 2329 ns 2329 ns 302911
BM_SkRegion_IntersectsSingleRect/Medium 60436 ns 60183 ns 11156
BM_DlRegion_IntersectsSingleRect/Large 1243 ns 1243 ns 565209
BM_SkRegion_IntersectsSingleRect/Large 2813 ns 2813 ns 252187
BM_DlRegion_IntersectsRegion/Tiny 38.9 ns 38.9 ns 17913855
BM_SkRegion_IntersectsRegion/Tiny 203 ns 203 ns 3480855
BM_DlRegion_IntersectsRegion/Small 306 ns 306 ns 2295413
BM_SkRegion_IntersectsRegion/Small 1057 ns 1057 ns 660826
BM_DlRegion_IntersectsRegion/Medium 8.83 ns 8.83 ns 79128233
BM_SkRegion_IntersectsRegion/Medium 43.3 ns 43.3 ns 16076912
BM_DlRegion_IntersectsRegion/Large 6.96 ns 6.96 ns 101646676
BM_SkRegion_IntersectsRegion/Large 31.8 ns 31.8 ns 22121517
BM_DlRegion_IntersectsRegion/TinyAsymmetric 54.2 ns 54.2 ns 12890870
BM_SkRegion_IntersectsRegion/TinyAsymmetric 4575 ns 4574 ns 155368
BM_DlRegion_IntersectsRegion/SmallAsymmetric 190 ns 189 ns 3748547
BM_SkRegion_IntersectsRegion/SmallAsymmetric 6157 ns 6157 ns 114403
BM_DlRegion_IntersectsRegion/MediumAsymmetric 20.9 ns 20.9 ns 33523941
BM_SkRegion_IntersectsRegion/MediumAsymmetric 3247 ns 3247 ns 214694
BM_DlRegion_IntersectsRegion/LargeAsymmetric 8.97 ns 8.97 ns 76827676
BM_SkRegion_IntersectsRegion/LargeAsymmetric 154 ns 154 ns 4757924
BM_DlRegion_Operation/Union_Tiny 26.3 us 26.3 us 24534
BM_SkRegion_Operation/Union_Tiny 37.9 us 37.9 us 17973
BM_DlRegion_Operation/Union_Small 64.4 us 64.4 us 10657
BM_SkRegion_Operation/Union_Small 105 us 105 us 6278
BM_DlRegion_Operation/Union_Medium 22.0 us 22.0 us 31631
BM_SkRegion_Operation/Union_Medium 64.8 us 64.8 us 10744
BM_DlRegion_Operation/Union_Large 1.00 us 1.00 us 697406
BM_SkRegion_Operation/Union_Large 1.29 us 1.29 us 547089
BM_DlRegion_Operation/Union_TinyAsymmetric 10.3 us 10.3 us 68647
BM_SkRegion_Operation/Union_TinyAsymmetric 20.6 us 20.6 us 33282
BM_DlRegion_Operation/Union_SmallAsymmetric 14.0 us 14.0 us 49944
BM_SkRegion_Operation/Union_SmallAsymmetric 34.4 us 34.4 us 19618
BM_DlRegion_Operation/Union_MediumAsymmetric 5.24 us 5.24 us 134097
BM_SkRegion_Operation/Union_MediumAsymmetric 12.7 us 12.7 us 55069
BM_DlRegion_Operation/Union_LargeAsymmetric 0.376 us 0.376 us 1808589
BM_SkRegion_Operation/Union_LargeAsymmetric 0.533 us 0.532 us 1283674
BM_DlRegion_Operation/Intersection_Tiny 8.13 us 8.13 us 87199
BM_SkRegion_Operation/Intersection_Tiny 31.8 us 31.8 us 21864
BM_DlRegion_Operation/Intersection_Small 55.9 us 55.9 us 11888
BM_SkRegion_Operation/Intersection_Small 98.4 us 98.3 us 6963
BM_DlRegion_Operation/Intersection_Medium 40.0 us 40.0 us 17667
BM_SkRegion_Operation/Intersection_Medium 69.8 us 69.8 us 9910
BM_DlRegion_Operation/Intersection_Large 1.06 us 1.06 us 650957
BM_SkRegion_Operation/Intersection_Large 1.26 us 1.26 us 559624
BM_DlRegion_Operation/Intersection_TinyAsymmetric 2.62 us 2.62 us 264565
BM_SkRegion_Operation/Intersection_TinyAsymmetric 15.3 us 15.3 us 45528
BM_DlRegion_Operation/Intersection_SmallAsymmetric 7.15 us 7.15 us 93482
BM_SkRegion_Operation/Intersection_SmallAsymmetric 27.5 us 27.5 us 24450
BM_DlRegion_Operation/Intersection_MediumAsymmetric 2.95 us 2.95 us 235133
BM_SkRegion_Operation/Intersection_MediumAsymmetric 10.5 us 10.5 us 65925
BM_DlRegion_Operation/Intersection_LargeAsymmetric 0.165 us 0.165 us 4016433
BM_SkRegion_Operation/Intersection_LargeAsymmetric 0.409 us 0.409 us 1719716
BM_DlRegion_Operation/Intersection_SingleRect_Tiny 0.105 us 0.105 us 7403099
BM_SkRegion_Operation/Intersection_SingleRect_Tiny 10.8 us 10.8 us 64185
BM_DlRegion_Operation/Intersection_SingleRect_Small 0.410 us 0.410 us 1724524
BM_SkRegion_Operation/Intersection_SingleRect_Small 16.2 us 16.2 us 43707
BM_DlRegion_Operation/Intersection_SingleRect_Medium 0.458 us 0.458 us 1540049
BM_SkRegion_Operation/Intersection_SingleRect_Medium 7.54 us 7.54 us 93407
BM_DlRegion_Operation/Intersection_SingleRect_Large 0.175 us 0.175 us 3984926
BM_SkRegion_Operation/Intersection_SingleRect_Large 0.351 us 0.351 us 1931946
BM_DlRegion_FromRects/Tiny 154 us 154 us 4383
BM_SkRegion_FromRects/Tiny 69429 us 69419 us 10
BM_DlRegion_FromRects/Small 369 us 369 us 1932
BM_SkRegion_FromRects/Small 117584 us 117578 us 6
BM_DlRegion_FromRects/Medium 475 us 475 us 1477
BM_SkRegion_FromRects/Medium 21611 us 21610 us 33
BM_DlRegion_FromRects/Large 1329 us 1329 us 533
BM_SkRegion_FromRects/Large 1409 us 1409 us 501
BM_DlRegion_GetRects/Tiny 39.2 us 39.2 us 18030
BM_SkRegion_GetRects/Tiny 84.2 us 84.2 us 9971
BM_DlRegion_GetRects/Small 88.9 us 88.9 us 7873
BM_SkRegion_GetRects/Small 212 us 212 us 3598
BM_DlRegion_GetRects/Medium 0.845 us 0.813 us 881224
BM_SkRegion_GetRects/Medium 3.10 us 3.09 us 223483
BM_DlRegion_GetRects/Large 0.120 us 0.120 us 5954761
BM_SkRegion_GetRects/Large 0.337 us 0.336 us 2068656
```
## 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 Hixie said 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
[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
Fixes: https://github.com/flutter/flutter/issues/128159
In diagnosing test failures for https://github.com/flutter/engine/pull/42330 we discovered that the DisplayList code was not always backwards compatible with computing the bounds of inverted rectangles (where left > right or top > bottom). Historically such rectangles were always rendered as if they were sorted (i.e. `SkRect::makeSorted()`), but we computed bounds as if the bounds only mattered if the supplied rectangle was ordered. So, we would sometimes render a rectangle for which we mis-computed the bounds.
This would rarely surface in the current code as most rendered rectangles would pass through `SkMatrix::mapRect()` which implicitly orders the rectangle as it transforms it, but any attributes applied to the bounds before that method may have been applied "in the wrong direction" - such as:
- stroke width padding
- mask blur padding
- image filter padding
Fixes https://github.com/flutter/flutter/issues/116070
Fixes https://github.com/flutter/flutter/issues/126202
Introduces `DlRegion` class which implements subset of `SkRegion`
required to get non-overlapping rectangles from region.
The implementation is different and faster than `SkRegion` for this
particular use-case (`display_list_region_benchmarks`):
Edit: Updated benchmark to latest revision and natively (initial run
went through rosetta)
```
----------------------------------------------------------------------------
Benchmark Time CPU Iterations
----------------------------------------------------------------------------
BM_RegionBenchmarkDlRegion/Tiny 616 us 616 us 908
BM_RegionBenchmarkSkRegion/Tiny 70559 us 70557 us 10
BM_RegionBenchmarkDlRegion/Small 1315 us 1314 us 537
BM_RegionBenchmarkSkRegion/Small 121736 us 121717 us 6
BM_RegionBenchmarkDlRegion/Medium 1079 us 1079 us 650
BM_RegionBenchmarkSkRegion/Medium 22039 us 22035 us 32
BM_RegionBenchmarkDlRegion/Large 399 us 399 us 1763
BM_RegionBenchmarkSkRegion/Large 1510 us 1510 us 466
```
## 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 Hixie said 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
[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
The original PR caused some golden test failures down the line, likely due to bad analysis of when the combined BlendMode and color would result in a NOP situation.
This PR adds tests that go through every BlandMode and pair it with a variety of colors and Color/ImageFilters to verify that the operations are only omitted when they actually produce no change in the output. It also checks the validity of the "modifies_transparent_black" property of DisplayLists which can be used in place of the current CanvasSpy/DlOpSpy classes.
The description from the [previous PR](https://github.com/flutter/engine/pull/41463) updated with the new name of the DL property:
---------------------------------
This optimization avoids recording unnecessary render operations that will not affect the output and also eliminates the need for "draw detection" mechanisms like `DlOpSpy` and `CanvasSpy` by remembering if any non-transparent operations were included. The `DlOpSpy` unit tests were updated to check if the results from that object match the new `DisplayList::modifies_transparent_black()` method.
Fixes https://github.com/flutter/flutter/issues/125338
In addition, this change will unblock some other Issues:
- https://github.com/flutter/flutter/issues/125318
- https://github.com/flutter/flutter/issues/125403
