Measure invalidation performance and fixes (batching version) #24823
Conversation
- Do not bubble up `MeasureInvalidated` on pages - Invoke `MeasureInvalidated` just once when `BindingContext` is changing - Do not synchronously measure/arrange children on legacy layout upon child measure invalidated: simply wait for the next native layout pass
… switch branches
…parent correctly
…e to invalidate parent chain through the platform view on `ScrollView` (iOS)
| frame = control.Frame; | ||
| desiredSize = control.DesiredSize; | ||
| Assert.Equal(5, frame.X, 0.5d); | ||
| Assert.Equal(60, frame.Width, 0.5d); |
There was a problem hiding this comment.
This was failing on ListView and TableView due to the fact they were not propagating SetNeedsLayout to the parent.
|
Thank you so much for your work, can't wait to try it out! Do you think or have you tested if it will also affect performance of rendering pages when navigating/performing first render? Currently navigation can be a lot slower than Xamarin in certain cases, sometimes even with static pages without binding and collections. |
|
@OvrBtn it improves that a bit if you're using |
albyrock87
changed the title
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
@albyrock87 great work! What about android, which seems to be the slowest platform overall so far in .net maui, have you seen even bigger improvements? |
Description of Change
This is #24532 plus batching of measure invalidation.
I executed a speedscope on davidortinau/AllTheLists
LearningPageusing the latest nightly8.0.99-ci.net8.24468.1build.What I noticed is that #23052
OnChildMeasureInvalidatedInternalwas showing up and taking 2% of total time (recursive calls).What I've done:
BindingContexton attached nodes by batching layout invalidation during binding context change & propagationBindingContextchanges, from the leaf to the rootHandler = null)SetNeedsLayoutpropagation issues and cleans up detection of autoSetNeedsLayoutparent propagation withIPropagatesSetNeedsLayoutinternal interfaceWinUI Speedscope
Kindly provided by @MartyIX
Before
main1726728202.MAIN.speedscope.json
After
PR1726728309.PR.speedscope.json
Before
main1726728235.MAIN.speedscope.json
After
PR1726728360.PR.speedscope.json
Android Speedscope
Before
mainandroid-before.speedscope.json
After
PRafter-android.speedscope.json.zip
iOS Speedscope
Before
mainbefore.speedscope.json.zip
After
PRafter.speedscope.json.zip
Before
mainYou can notice there are some hiccups while scrolling.
before.mp4
After
PRYou can notice there hiccups are basically gone while scrolling, even if in this case I had a lot more nested children.
after.mp4
Issues Fixed
Fixes #24551