Floating point rounding warning

[kavantix]

Floating point rounding warning

[Kavantix]

@jseminck thanks for reporting this!
If you have a minimal reproducible example that would be very helpful.

However, from you logs I see that it is indeed simply a rounding error like the error message says.
The problem is that that rounding error is hard to fix, it can even happen if I set the paintOrigin to 0 and the paintExtent to constraints.remainingPaintExtent (so they should be identical)

If this happens often and we have an example to test with a solution might be to round the paint origin and paint extent to prevent this from happening since the clamp/max method they suggest does not work

[jseminck]

Hey, thanks for the quick reply. In our app it is reproduced every time when swiping up using the CupertinoSliverRefreshControl component inside a MultiSliver. So if I manage to extract and simplify this then it should help. I'll do my best to set up a minimum reproducible example over the weekend.

[jseminck]

I created a small example application here: https://github.com/jseminck/multisliver-example-app

FYI: the sliver tools version is fixed to 0.1.9 because we also have an issue with the upgrade to 0.1.10. I explained that issue as well in the README. It's something we eventually need to tackle as well. We have a custom widget that works together with MultiSliver but some changes in the latest version were breaking some functionality for us.

[Kavantix]

Thanks! i’ll take a look to the code later today.
as for the version change, 0.1.9 had incorrect behavior so you should definitely use the latest version.
What was breaking for you was probably that I did not correctly pass the preceedingScrollExtent to the children of the MultiSliver, so your custom widget should also not work as you intend if it’s not inside a MultiSliver.

[Kavantix]

Btw, for the behavior you describe you should be able to simply use a normal SliverFillRemaining. The default one that has hasScrollBody as true will simply always fill the entire remainingPaintExtent or at least be as big as it’s child.

[jseminck]

Thanks for the replies. I actually tried the SliverFillRemaining as well but it allows me to scroll past the current content, which our custom widget does not allow. I'm still fairly new to Flutter and building on top of some of the things my team did, so still also trying to wrap my head around the whole Sliver stuff. 😄

It seems the only change we made to SliverFillRemaining is to pass an offset and subtract it here:
https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/rendering/sliver_fill.dart#L214

This is the offset that we set
https://github.com/jseminck/multisliver-example-app/blob/main/lib/main.dart#L81

with SliverFillRemaning

with SliverFillRemaningCustom

[jseminck]

After some more debugging I'm starting to have a feeling our setup may have only worked because of the incorrect behavior in 0.1.9, because in 0.1.10 it doesn't seem to matter at all if I am using a MultiSliver component or not. 😄

[Kavantix]

Yes exactly and that’s how it is supposed to work, as if it was directly in the customscrollview :)
But since in 0.1.9 the precedingScrollExtent is always 0 for the first sliver in the multisliver that should lead you to get your custom one to work ;)

[Kavantix]

The error should no longer occur in the 0.2.0 version I just released.

As for you widget that doesnt work, try using something like this:

class SliverConstraintsManipulator extends SingleChildRenderObjectWidget {
  final SliverConstraints Function(SliverConstraints) manipulator;

  const SliverConstraintsManipulator({
    Key key,
    @required Widget child,
    @required this.manipulator,
  }) : super(key: key, child: child);

  @override
  RenderSliverConstraintsManipulator createRenderObject(BuildContext context) {
    final renderObject = RenderSliverConstraintsManipulator();
    updateRenderObject(context, renderObject);
    return renderObject;
  }

  @override
  void updateRenderObject(BuildContext context,
      covariant RenderSliverConstraintsManipulator renderObject) {
    renderObject.manipulator = manipulator;
  }
}

class RenderSliverConstraintsManipulator extends RenderProxySliver {
  SliverConstraints Function(SliverConstraints) get manipulator => _manipulator;
  SliverConstraints Function(SliverConstraints) _manipulator;
  set manipulator(SliverConstraints Function(SliverConstraints) manipulator) {
    if (manipulator != _manipulator) {
      _manipulator = manipulator;
      markNeedsLayout();
    }
  }

  @override
  void performLayout() {
    if (child == null) {
      geometry = SliverGeometry.zero;
      return;
    }
    child.layout(manipulator(constraints), parentUsesSize: true);
    geometry = child.geometry;
  }
}

This lets you manipulate the constraints that get passed to the child.
So you could for instance get the old incorrect behaviour by wrapping the MultiSliver with one of these and setting the manipulator to:

manipulator: (constraints) => constraints.copyWith(precedingScrollExtent: 0),

I might add something like this to the package if there are more usecases for it, let me know if you have any

[jseminck]

Thank you so much @Kavantix ! I will try this approach as well later today. In the end I figured out something like this also seemed to work: jseminck/multisliver-example-app#1 -- I tried it in our app and found no issues, but I need to discuss it further with the team as well. My approach is a bit more limited though 😄