Slider relies on brittle paint order to work properly

[goderbauer]

The material Slider widget relies on the order in which nodes get precessed during PAINT in order to present itself visually correctly. That's brittle.

Here's the problem: In its paint method _RenderSlider configures the paintValueIndicator painter...

flutter/packages/flutter/lib/src/material/slider.dart

Line 1453 in 5684b9f

_state.paintValueIndicator = (PaintingContext context, Offset offset) {

... which is used in the paint method of _RenderValueIndicator:

flutter/packages/flutter/lib/src/material/slider.dart

Line 1611 in 5684b9f

_state.paintValueIndicator?.call(context, offset);

This only works if _RenderSlider is processed before _RenderValueIndicator during PAINT. Otherwise, _RenderValueIndicator.paint will not see the painter configured by _RenderSlider.paint and instead paint with an outdated painter.

Since nodes are processed from deepest to shallowest, this works fine when _RenderSlider is deeper in the tree than _RenderValueIndicator and breaks otherwise. It will also break when the order in which we process nodes during PAINT is flipped around as we did in #98219, which may give us some performance benefits. That PR saw breakages in google3 because of the problem described here (see b/219153804).

Long story short: Slider should not relay on the somewhat brittle order in which nodes get processed during PAINT.

Side node: We should also add a test for this to the framework since this was only caught during a google3 roll. Done: #98772

[goderbauer]

That behavior was introduced in #53916. @HansMuller @JoseAlba @clocksmith

[TahaTesser]

@goderbauer
I wanna pick your brain regarding Slider. I noticed Slider uses FocusableActionDetector on entire _SliderRenderObjectWidget, which paints track, thumb and value indicator altogether.

I wanna be able to detect hover/focus just on thumbs to update overlays and as well as to add support thumb overlays in RangeSlider, as it has 2 thumbs, detecting which thumb is hovered and focused is very important.

I was thinking instead, I could use CustomMultiChildLayout or MultiChildRenderObjectWidget to render all these components individually.

Something like this:

        child: CompositedTransformTarget(
          link: _layerLink,
          child: CustomMultiChildLayout(
            delegate: _SliderLayoutDelegate(),
            children: <Widget>[
              LayoutId(
                id: _SliderChildSlot.sliderTrack,
                child: _SliderTrackObjectWidget(
                  ...
                ),
              ),
              LayoutId(
                id: _SliderChildSlot.sliderThumb,
                child: _SliderThumbObjectWidget(
                  ...
                ),
              ),
              LayoutId(
                id: _SliderChildSlot.sliderValueIndicator,
                child: _SliderValueIndicatorObjectWidget(
                  ...
                ),
              ),
            ],
          ),
        ),

This only works if _RenderSlider is processed before _RenderValueIndicator during PAINT. Otherwise, _RenderValueIndicator.paint will not see the painter configured by _RenderSlider.paint and instead paint with an outdated painter.

Would this also help this issue? Wouldn't this also ensure _RenderSlider is rendered before _RenderValueIndicator?

[TahaTesser]

Fixing #111451, I noticed overlay issues in Slider, which makes M3 overlay tokens inconsistent and I also want add overlay support to RangeSlider so it can use M3 overlay tokens as well.

cc: @HansMuller