Improvements to estimateMaxScrollOffset

[Piinks]

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:

https://github.com/flutter/flutter/blob/f82c020071667d723017aab328c09ba70617bf7c/packages/flutter/lib/src/widgets/sliver.dart#L1281

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 estimateMaxScrollOffset for any SliverChildDelegate, but if there are more approachable options we should explore further

Related to https://github.com/flutter/flutter/issues/25652

[chipweinberger]

I looked over some of your scrolling PRs and want to strongly request we replace/supplant ListView.itemExtent (double) with ListView.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]

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 with SliverList.

(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]

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.