mirror of
https://github.com/flutter/flutter.git
synced 2026-02-20 02:29:02 +08:00
7f453eb089
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
Engine Testing
This directory contains the infrastructure for running tests on the engine, which are most often run by Flutter's continuous integration (CI) systems.
The tests themselves are located in other directories, closer to the source for
each platform, language, and variant. For instance, macOS engine unit tests
written in objective C are located in the same directory as the source files,
but with a Test suffix added (e.g. "FlutterEngineTest.mm" holds the tests for
"FlutterEngine.mm", and they are located in the same directory).
Testing the Engine locally
If you are working on the engine, you will want to be able to run tests locally.
In order to learn the details of how do that, please consult the Flutter Wiki page on the subject.