Closed
Description
Now that we have an open DisplayList format for the Flutter engine, we should be able to look at some further optimizations that have been blocked by our reliance on SkPicture. This issue will track the planned and wished changes that we can now consider. Individual work on these items should be correlated here with an Issue or PR number.
One near-term change that will be needed before any follow-on work takes effect will be to flip the switch to enable the new DisplayList format by default (see PR: flutter/engine#27130)
- Missing featuresCleanup & debugabilityImprove the raster cachePerformance optimizations
- Avoid a save layer when modifying the opacity of simple children (suggested in Issue OpacityLayer causes sharp increases in memory usage in trivial apps #75697) (now may be higher priority to enable Android Q transition animations as mentionedin Revert "Reland "Android Q transition by default (#82670)"" #88482 (comment))
Performance analysis and debugging- Make DLs inspectable so that that a programmer or DevTools can ask what a Picture has in it.
Expose the DL to the framework- Be able to edit/splice and monitor the regeneration of DLs from the Framework when Widgets/RenderObjects enter or leave a given group that produced a specific prior Picture rather than regenerate the DL from scratch
- The ability to refer to / name / inspect / manipulate DL subsequences in the framework, e.g. so the framework can say things like, "Just use a subset of the same DL as the last time."
- Be able to notice when a DL is being recreated exactly the same as it was previously when a group of Widgets/RenderObjects are told to repaint even though they haven't changed - both as a debugging tool to detect unnecessary repaints and as an optimization to prevent such "unnecessary redraw" from affecting the raster cache
Evaluate and improve DL implementation efficiency- Look at the use of
sk_sp<SkThing>
vsSkThing*
in the Dispatcher methods to avoid extra ref/unrefs. Note that you can create ansk_sp<>
from a pointer usingsk_ref_sp
so that it might make sense to only have pointers in the methods and only storesk_sp
in the DL records. This would eliminate a lot of extra ref/unrefs for dispatchers that don't need to "own" the objects beyond their implementation of the method. - Improve the ability to deep compare Skia objects used in the DisplayList (may require either pressing Skia to make the objects inspectable and comparable, or removing the Skia objects in favor of inlined data as per the previous bullet item)
- Investigate alternate storage mechanisms (the current mechanism was adapted from Skia's SkLiteDL, and is rigorously type checked and has the advantages of a flat layout that is both fast to compare and destruct and will enhance memory locality, but could be implemented in a way to be naturally type-safe)
- Short-circuit DL analysis.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
✅ Done
Milestone
Relationships
Development
No branches or pull requests
Activity
chinmaygarde commentedon Jul 15, 2021
We discussed this yesterday and Zach is going to compile a concrete list of work items from this list.
zanderso commentedon Jul 16, 2021
I've categorized the items. After that I'll work on filing individual issues, and linking them up here.
[-]Take advantage of new DisplayList format[/-][+]☂️ - Take advantage of new DisplayList format[/+]FelixZhang00 commentedon Dec 3, 2021
@flar Can we use parallel work threads to reduce time like chromium did.
see also: https://chromium-review.googlesource.com/c/chromium/src/+/1169150
flar commentedon Dec 3, 2021
It looks like you are asking if we can use a recorder to split the work between UI and raster threads. That has always been the design of Flutter since the early days. The DisplayList is just a new recording format that replaces the Skia recording format, but the basic division of labor remains "record on UI thread, rasterize on raster thread".
FelixZhang00 commentedon Dec 4, 2021
Thanks for your reply.
What I mean is that we divide layer into tiles and raster tiles with a pool of dedicated raster threads.
flar commentedon Dec 4, 2021
That would be out of the scope of this PR which is more about capabilities of the storage format itself. You should file a separate engine issue for that idea. DL might be able to add some features to make that more feasible, but such a change would require extensive changes to the way that the layer trees are painted.
chinmaygarde commentedon Jun 28, 2022
I have migrated the contents of this umbrella issue to a GitHub project here Display List (go/display-list-project for Googlers).
github-actions commentedon Jul 29, 2022
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
flutter doctor -v
and a minimal reproduction of the issue.