-
Notifications
You must be signed in to change notification settings - Fork 543
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
Optimize StandardTableView in Fluent, Material and Native styles #3425
Conversation
@bjorn thank you very much for the PR. Would you like to add this optimization also for the |
By using a ListView instead of a ScrollView + VerticalLayout, we trigger the optimization where only visible children are being instantiated. For the Fluent style, this was making the rows more compact, so I've added additional padding to the TableViewCell to compensate. I don't know where the padding used to come from. I didn't touch Cupertino style since it's currently work-in-progress. This optimization can be done there as well. For the Native style, this optimization isn't as straight-forward because it uses a NativeScrollView + Flickable directly rather than a the ScrollView.
0a74464
to
7a68c7d
Compare
@FloVanGH Alright, done. As for
Would still be nice if anybody had an idea why my change destroyed the original padding. |
Using the ListView makes it possible to only instantiate the visible items, which makes the StandardTableView a lot faster for larger models (already very noticeably in the gallery example). When using a ListView, StandardTableView lost access to the NativeScrollView.native-padding-top/left properties, which are now exposed through the ScrollView item. It could also no longer position the Flickable below the header (or in doing so, would take the scrollbar along with it), so a property was added to ScrollView for that purpose as well.
7a68c7d
to
3096b06
Compare
So, the |
This avoids exposing additional properties on the ScrollView for just the native style.
Added minimum size, preferred size and stretch factors (they were not present before introducing InternalScrollView either, but are added now for consistency with the other styles).
Looks good to me, thank you very much! |
* Optimize StandardTableView in Fluent and Material styles By using a ListView instead of a ScrollView + VerticalLayout, we trigger the optimization where only visible children are being instantiated. For the Fluent style, this was making the rows more compact, so I've added additional padding to the TableViewCell to compensate. I don't know where the padding used to come from. I didn't touch Cupertino style since it's currently work-in-progress. This optimization can be done there as well. For the Native style, this optimization isn't as straight-forward because it uses a NativeScrollView + Flickable directly rather than a the ScrollView. * Optimize StandardTableView for Native style Using the ListView makes it possible to only instantiate the visible items, which makes the StandardTableView a lot faster for larger models (already very noticeably in the gallery example). When using a ListView, StandardTableView lost access to the NativeScrollView.native-padding-top/left properties, which are now exposed through the ScrollView item. It could also no longer position the Flickable below the header (or in doing so, would take the scrollbar along with it), so a property was added to ScrollView for that purpose as well. * Introduced InternalScrollView This avoids exposing additional properties on the ScrollView for just the native style. * Fix missing default values for Native style ScrollView Added minimum size, preferred size and stretch factors (they were not present before introducing InternalScrollView either, but are added now for consistency with the other styles). (cherry picked from commit 74b37df)
By using a
ListView
instead of aScrollView
+VerticalLayout
, we trigger the optimization where only visible children are being instantiated. In my application it makes a very noticeable difference.For some reason, changing to
ListView
made the existing vertical padding disappear. I don't know where this padding came from before, but I've restored it by adding padding to theTableViewCell
.If this optimization is correct I can look into doing the same for other styles.