-
Notifications
You must be signed in to change notification settings - Fork 27.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add benchmark case for RasterCache #103338
Add benchmark case for RasterCache #103338
Conversation
═════════════════════════╡ ••• Final A/B results ••• ╞══════════════════════════ Score Average A (noise) Average B (noise) Speed-up cc @flar |
f018e83
to
7d7fb04
Compare
7d7fb04
to
a2e1967
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with config changes. /cc @flar may need to review the test codes.
Can you describe what this benchmark is aiming to test? Are there specific cases of double-caching in here that we should find eliminated with the upcoming raster pass fix? Is it more of a general "how fast is caching" benchmark? Also, the sizes are pretty big, I don't think I'm seeing all of the content here. We run these benchmarks in labs that mostly consist of Moto G4 phones and I can barely see the top of the first logo briefly. Much of the content is probably never rendered due to bounds testing. Even running on my Mac screen the content is too big for the screen. |
Score Average A (noise) Average B (noise) Speed-up And by this change, the display is normal on my device(HUAWEI device, the screen size is 5.5 inches, screen resolution is 720*1280), and above is the benchmark data |
@flar Friendly ping. |
91c838e
to
8b267cb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Add a scenario for test raster cache memory use and render time
flutter/engine#31892
In this benchmark test scenario, I build a ListView that will have 3 Children, the first LayerTree is an ImageFilterLayer and a DisplayListLayer, the second LayerTree is a ShaderMaskLayer subtree, and the third is a DisplayListLayer.
According to the existing RasterCache logic, the ImageFilterLayer will be cached many times because it is a bottom-up cache process.
However, this PR differentiates the RasterCache process and changes it to a top-down logic, so that once the parent ImageFilterLayer is cached, the child node will not have any extra cache.
The Layer tree is shown in the following figure
cc @flar