-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Closed
Labels
P1High-priority issues at the top of the work listHigh-priority issues at the top of the work listc: new featureNothing broken; request for a new capabilityNothing broken; request for a new capabilityc: performanceRelates to speed or footprint issues (see "perf:" labels)Relates to speed or footprint issues (see "perf:" labels)engineflutter/engine related. See also e: labels.flutter/engine related. See also e: labels.
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 features
- Cleanup & debugability
- DisplayList objects should be held by SkiaGPUObject wrappers #90237
- Remove Engine flag for disabling the DisplayList #86634
- Implement SkCanvas::OnDrawShadowRect() in the Skia->DisplayList adapter #86635
- Test DrawAtlas and DrawVertices with Arithmetic Blenders #86713
- Make the DisplayList more developer friendly #86714
- Implement DisplayList serialization #86715
- Generate DisplayList record types from a declarative manifest #86716
- Update DisplayList method names for Flutter style guidelines #90232
- ui.Canvas native methods should call DisplayListBuilder methods directly #93415
- Teach Paragraph code to use DisplayListBuilder calls instead of SkCanvas #93417
- Write API documentation for the DisplayList classes #93673
- DisplayList DispatchHelpers should protect against extra restore calls #100176
- Create better names for the DisplayList transform methods #100175
- Builder should have getters for matrix and clip #100173
- Improve the raster cache
- Picture Cache complexity metrics should include nested SkPicture/DisplayList op counts #91621
- Determine relative cost of DisplayList operations #86717
- Tune thresholds for when to deep compare DisplayList objects #86724
- Include the relative complexity of DisplayLists when prioritizing raster cache entries #86728
- Expand the raster cache to include DisplayList objects embedded in other DisplayList objects #87584
- Raster cache heuristics are bad. #88832
- ☂️ - Improved raster cache heuristics for complex pictures #87833
- Performance optimizations
- OpacityLayer and ColorFilterLayer should detect if their children can be drawn without a saveLayer #92874
- 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))
- Collapse bounds calculations into DisplayListBuilder #100172
- RasterCache could reuse or combine (i.e. atlas) SkSurfaces during composited scale animations #83189
- Engine RasterCache usage can lead to double-caching of layers #70124
- Flare in Stack - disappearing when widget tree repaints #69615
- DisplayList has no proactive culling as was available in SkPicture #92740
- OpacityLayer peephole optimization does not optimize multiple non-overlapping children #93899
- OpacityLayer and ColorFilterLayer should detect if their children can be drawn without a saveLayer #92874
- Performance analysis and debugging
- Add annotations to the DisplayLists to indicate which Flutter widget generated them #86804
- Make DLs inspectable so that that a programmer or DevTools can ask what a Picture has in it.
- Expose the DL to the framework
- Allow the framework to compare Pictures #86806
- 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
- Make the display list interface graphics package neutral. #95434
- 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_spso that it might make sense to only have pointers in the methods and only storesk_spin 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.
- DisplayList should compute bounds directly #91060
zanderso, jonahwilliams, chinmaygarde, b3nni97, iskakaushik and 19 more
Metadata
Metadata
Assignees
Labels
P1High-priority issues at the top of the work listHigh-priority issues at the top of the work listc: new featureNothing broken; request for a new capabilityNothing broken; request for a new capabilityc: performanceRelates to speed or footprint issues (see "perf:" labels)Relates to speed or footprint issues (see "perf:" labels)engineflutter/engine related. See also e: labels.flutter/engine related. See also e: labels.
Type
Projects
Status
✅ Done