computeMinIntrinsicWidth method Null safety

@override

double computeMinIntrinsicWidth(

double height

)

override

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

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 supposed to render 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.

Implementation

@override
double computeMinIntrinsicWidth(double height) {
  assert(height >= 0.0);
  if (_width == null && _height == null) {
    return 0.0;
  }
  return _sizeForConstraints(BoxConstraints.tightForFinite(height: height)).width;
}