Repository navigation
Improvements to estimateMaxScrollOffset #97676
Description
Chatted with @HansMuller about this the other day.
Currently, Flutter only estimates the maximum scroll offset one way, but taking the average size of the visible children and multiplying it by the number of children:
This can be a bit unfortunate when the user has a list of dynamically sized items in which the max scroll extent changes as they scroll.
There seem to be some opportunities for improvement here. Things we might consider:
- Adding more strategies for estimating the max scroll offset for different situations
- optionally could let the user decide which estimation method they would like used
- One should be that we cache the metrics as we go, rather than disposing of extent info of children we have scrolled past already
- Better expose an option for users to provide their own estimate
- could just involve a good example or two showing how to override
estimateMaxScrollOffsetfor any SliverChildDelegate, but if there are more approachable options we should explore further
- could just involve a good example or two showing how to override
Related to #25652
Activity
chipweinberger commentedon Mar 3, 2022
I looked over some of your scrolling PRs and want to strongly request we replace/supplant
ListView.itemExtent (double)withListView.itemExtentList (List<double>).The programmer knows a lot about the sizes of things and how user actions can impact size.
For example, if a user hits a button that expands all or some the widgets inside the
ListView, the programmer knows which ones are now the new size.It also lets the programmer associate a scrollOffset with a specific item, which is needed for jumping to a known item using the scrollOffset. Today, event if the programmer knows where an item is, they still can't jump to it correctly because Flutter doesn't know where it is.
knopp commentedon Sep 26, 2022
We've published first version of
SuperSliverList, you can see live example here. The average item estimation is simply(last item paint offset + extent)/(last item index + 1). In the example you can see that the scrollbar is much "calmer" than withSliverList.(I'm not saying this is better algorithm that what Flutter uses in Sliver list, it's just better suitable for our use-case).
0921dma commentedon Oct 11, 2023
Is there a way to implement a similar solution for SliverAnimatedList as described in this issue? I'm facing the same issue due to the dynamic sizes of the list items, and I'm wondering if there's a workaround or an upcoming fix for SliverAnimatedList as well.
Fix jittery scrollbars
Fix jittery scrollbars