In super_sliver_list we rely on scrollOffsetCorrection to account for the difference between estimated and actual extent. In some corner cases, for example when the viewport is initially scrolled to end, this may result in one correction per SuperSliverList during initial layout.
The problem is that RenderViewport currently caps the maximum number of of layout cycles to 10, regardless of number of slivers. In case where there is a large amount of very short slivers, this may throw an exception, even though each sliver only requested at most one correction.
Ideally we'd want to track the number of correction requests per Sliver, but that's little bit difficult because slivers can be nested (i.e. SliverMainAxisGroup) and SliverGeometry propagated from child slivers does not carry the original sliver that requested the correction.
Less ideal but much easier solution would be to replace _maxLayoutCycles with _maxLayoutCyclesPerChild and then multiply it with number of viewport children:
void performLayout() {
...
final int maxLayoutCycles = _maxLayoutCyclesPerChild * childCount;
...While not perfect, this would still be a significant improvement. We could potentially reduce the value of _maxLayoutCyclesPerChild from 10 because it will be multiplied by the amount of child slivers.
cc @Piinks
In super_sliver_list we rely on
scrollOffsetCorrectionto account for the difference between estimated and actual extent. In some corner cases, for example when the viewport is initially scrolled to end, this may result in one correction perSuperSliverListduring initial layout.The problem is that
RenderViewportcurrently caps the maximum number of of layout cycles to 10, regardless of number of slivers. In case where there is a large amount of very short slivers, this may throw an exception, even though each sliver only requested at most one correction.Ideally we'd want to track the number of correction requests per
Sliver, but that's little bit difficult because slivers can be nested (i.e.SliverMainAxisGroup) andSliverGeometrypropagated from child slivers does not carry the original sliver that requested the correction.Less ideal but much easier solution would be to replace
_maxLayoutCycleswith_maxLayoutCyclesPerChildand then multiply it with number of viewport children:While not perfect, this would still be a significant improvement. We could potentially reduce the value of
_maxLayoutCyclesPerChildfrom 10 because it will be multiplied by the amount of child slivers.cc @Piinks