computeMinIntrinsicWidth method
Computes the value returned by getMinIntrinsicWidth. Do not call this function directly, instead, call getMinIntrinsicWidth.
Override in subclasses that implement performLayout. This method should return the minimum width that this box could be without failing to correctly paint its contents within itself, without clipping.
If the layout algorithm is independent of the context (e.g. it always
tries to be a particular size), or if the layout algorithm is
width-in-height-out, or if the layout algorithm uses both the incoming
width and height constraints (e.g. it always sizes itself to
BoxConstraints.biggest), then the height argument should be ignored.
If the layout algorithm is strictly height-in-width-out, or is height-in-width-out when the width is unconstrained, then the height argument is the height to use.
The height argument will never be negative or null. It may be infinite.
If this algorithm depends on the intrinsic dimensions of a child, the
intrinsic dimensions of that child should be obtained using the functions
whose names start with get, not compute.
This function should never return a negative or infinite value.
Be sure to set debugCheckIntrinsicSizes to true in your unit tests if you do override this method, which will add additional checks to help validate your implementation.
Examples
Text
English text is the canonical example of a width-in-height-out algorithm.
The height argument is therefore ignored.
Consider the string "Hello World". The maximum intrinsic width (as returned from computeMaxIntrinsicWidth) would be the width of the string with no line breaks.
The minimum intrinsic width would be the width of the widest word, "Hello" or "World". If the text is rendered in an even narrower width, however, it might still not overflow. For example, maybe the rendering would put a line-break half-way through the words, as in "Hel⁞lo⁞Wor⁞ld". However, this wouldn't be a correct rendering, and computeMinIntrinsicWidth is defined as returning the minimum width that the box could be without failing to correctly paint the contents within itself.
The minimum intrinsic height for a given width smaller than the minimum intrinsic width could therefore be greater than the minimum intrinsic height for the minimum intrinsic width.
Viewports (e.g. scrolling lists)
Some render boxes are intended to clip their children. For example, the render box for a scrolling list might always size itself to its parents' size (or rather, to the maximum incoming constraints), regardless of the children's sizes, and then clip the children and position them based on the current scroll offset.
The intrinsic dimensions in these cases still depend on the children, even though the layout algorithm sizes the box in a way independent of the children. It is the size that is needed to paint the box's contents (in this case, the children) without clipping that matters.
When the intrinsic dimensions cannot be known
There are cases where render objects do not have an efficient way to compute their intrinsic dimensions. For example, it may be prohibitively expensive to reify and measure every child of a lazy viewport (viewports generally only instantiate the actually visible children), or the dimensions may be computed by a callback about which the render object cannot reason.
In such cases, it may be impossible (or at least impractical) to actually return a valid answer. In such cases, the intrinsic functions should throw when RenderObject.debugCheckingIntrinsics is false and asserts are enabled, and return 0.0 otherwise.
See the implementations of LayoutBuilder or RenderViewportBase for examples (in particular, RenderViewportBase.debugThrowIfNotCheckingIntrinsics).
Aspect-ratio-driven boxes
Some boxes always return a fixed size based on the constraints. For these
boxes, the intrinsic functions should return the appropriate size when the
incoming height or width argument is finite, treating that as a tight
constraint in the respective direction and treating the other direction's
constraints as unbounded. This is because the definitions of
computeMinIntrinsicWidth and computeMinIntrinsicHeight are in terms of
what the dimensions could be, and such boxes can only be one size in
such cases.
When the incoming argument is not finite, then they should return the actual intrinsic dimensions based on the contents, as any other box would.
See also:
- computeMaxIntrinsicWidth, which computes the smallest width beyond which increasing the width never decreases the preferred height.
Implementation
@override
double computeMinIntrinsicWidth(double height) {
_resolve();
final double totalHorizontalPadding = _resolvedPadding!.left + _resolvedPadding!.right;
final double totalVerticalPadding = _resolvedPadding!.top + _resolvedPadding!.bottom;
if (child != null) // next line relies on double.infinity absorption
return child!.getMinIntrinsicWidth(math.max(0.0, height - totalVerticalPadding)) + totalHorizontalPadding;
return totalHorizontalPadding;
}