-
Notifications
You must be signed in to change notification settings - Fork 26.9k
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
Enable Retained Rendering #21756
Comments
CC @Hixie @cbracken @chinmaygarde @jason-simmons @yjbanov @amirh Let's try to close this issue before the end of October so we can squeeze another 30% speedup? We'll also have to check the memory usage (thanks Chinmay for the remind). My guess is that the memory cost should be much less compared to our current raster cache: in my experiments, I only add the raster cache when there's an animated opacity. Those things should be much rarer than RepaintBoundaries and PictureLayers. Chinmay and I also think that we shall provide the raster cache option to the developers just like what we did with clipping. |
What would the API look like? |
For example, the constructor of |
Just found a bug in my experimentation which caused my program to never reuse the cache... So the 30% speedup is just by replacing After fixing the bug, the speedup is actually ~2.125x |
Can you elaborate on what "retained rendering" entails? |
Yes, retained rendering in my current experimental implementation means
|
Will changing Also, we should probably be consistent with the methods we provide to developers for controlling the raster cache. For example, we already have a concept of willChange. Perhaps we should use the same flag in |
Child of I also prefer |
Do you mean the engine treats it as a repaint boundary or the framework? I'm not aware of anything in the framework that treats it as a repaint boundary, and so the framework will hand you a new |
The framework has |
AFAICT, BTW, |
Oh, you're right. In my experiments, the Considering the cost of In any case, I did plan to add contraints to engine So to answer your original question, yes we'll have |
I'm not sure I understand how the dart:ui API is expected to look after this change. Can you elaborate on this? |
For
instead of
as Similarly, for
|
As discussed with @Hixie , we probably won't change the APIs of |
For retained rendering, we don't want to push the offset down to each leaf layer. Otherwise, changing an offset layer on the very high level could cascade the change to too many leaves, which means that we can't retain them. To not push the offset downwards, we simply push a TransformLayer when there's an offset. Skia has a fast path for concatenating scale/translation-only matrix so this operation should be fast (no performance regression is measured on Moto G4). This is our first step towards #21756
To make the PR minimal, we currently only share the engine layer when `pushPhysicalShape` (for Fuchsia) or `pushOffset` (for `RepaintBoundary` and `Opacity`) are called. They should be sufficient for our short-term perf goal. In the future, we can incrementally share more engine layers with the framework. flutter/flutter#21756
We first test this with OpacityLayer. This test alone (without retained rendering) should have ~30% speedup as we'll have fewer render target switches by snapshoting in the Preroll instead of saveLayer in the Paint. In my local flutter_gallery transition perf tests, the average frame time drops from ~16ms to ~12ms. flutter/flutter#21756
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of |
This is for tracking all related pull requests for enabling retained rendering.
In my local experiments, the retained rendering can speedup fading transition by 2.15x and put our flutter_gallery__transition_perf average_frame_rasterizer_time_millis well below 16ms on Moto G4. Hence it will fix #13736
The text was updated successfully, but these errors were encountered: