Skip to content
Boring Doc
BreakingHigh impactOfficial migration guidesince 2.0.0landed 1.25.0-4.0.pre

Dry layout support for RenderBox

Framework · Official source

A new method named `computeDryLayout` was added to the `RenderBox` protocol. Subclasses of `RenderBox` are expected to implement it to correctly report their desired size given a set of `BoxConstraints` during intrinsic calculations. Subclasses that implement `computeDryLayout` no longer need to override `performResize`.

Original behavior

A new method, `computeDryLayout`, was added to the `RenderBox` protocol to correctly calculate the intrinsic sizes of a `RenderParagraph` with `WidgetSpan` children and a `RenderWrap`. The method receives a set of `BoxConstraints` and is expected to calculate the resulting size of the `RenderBox` without changing any internal state. It's essentially a dry run of `performLayout` that only calculates the resulting size and doesn't place the children. The `computeDryLayout` method is part of the intrinsics protocol (see also `RenderBox.computeMinIntrinsicWidth` and friends).

New behavior

Subclasses of `RenderBox` need to override the new `computeDryLayout` method if they are used as a descendant of a `RenderObject` that may query the intrinsic size of its children. Examples of widgets that do this are `IntrinsicHeight` and `IntrinsicWidth`.

Who is affected
Applications and packages relying on the previous behaviour or signature. Code that uses RenderBox, BoxConstraints, RenderParagraph and related APIs.
Practical impact
Behaviour or API differences that can break builds or change runtime behaviour.
What action should I take?
Follow the official migration guide below, update affected call sites, run `dart fix --apply` where a fix is available, then run your tests.

Before and after (from the official guide)

dart+4−3
Before
1−@override
2− void performResize() {
3− size = constraints.biggest;
 
4 }
After
1+// This replaces the old performResize method.
2+ @override
3+ Size computeDryLayout(BoxConstraints constraints) {
4+ return constraints.biggest;
5 }
Raw before / after
@override
  void performResize() {
     size = constraints.biggest;
  }
// This replaces the old performResize method.
  @override
  Size computeDryLayout(BoxConstraints constraints) {
     return constraints.biggest;
  }
Official migration guide (excerpt, © The Flutter Authors, CC BY 3.0)

Subclasses that already override performResize can be migrated by simply changing the function signature from void performResize() to Size computeDryLayout(BoxConstraints constraints) and by returning the calculated size instead of assigning it to the size setter. The old implementation of performResize can be removed.

Code before migration:

  @override
  void performResize() {
     size = constraints.biggest;
  }

Code after migration:

  // This replaces the old performResize method.
  @override
  Size computeDryLayout(BoxConstraints constraints) {
     return constraints.biggest;
  }

If the subclass doesn't override performResize, the implementation of computeDryLayout has to be extracted from the performLayout method. Basically, computeDryLayout needs to do all the work performLayout is doing to figure out the size of the RenderBox. However, instead of assigning it to the size setter, it returns the computed size. If computeDryLayout needs to know the size of its children, it must obtain that size by calling getDryLayout on the child instead of calling layout.

If for some reason it is impossible to calculate the dry layout, computeDryLayout must call debugCannotComputeDryLayout from within an assert and return a dummy size of const Size(0, 0). Calculating a dry layout is, for example, impossible if the size of a RenderBox depends on the baseline metrics of its children.

  @override
  Size computeDryLayout(BoxConstraints constraints) {
    assert(debugCannotComputeDryLayout(
      reason: 'Layout requires baseline metrics, which are only available after a full layout.'
    ));
    return const Size(0, 0);
  }
Migration assistantAI-generated · grounded in cited sources
AI explanations are not configured
Set AI_PROVIDER (for example to openai-compatible with a local Ollama or LM Studio endpoint) to enable grounded explanations. Everything else on this page works without an AI provider.
Official migration guide·Verified classification (95%)

Listed in the official breaking-changes index (docs.flutter.dev/release/breaking-changes).

An official announcement or migration guide documents an intended behaviour or API change. A verified source change (git diff) shows code changed but does not by itself prove a public API is breaking. AI interpretations are labelled and never used to classify a change.

Source commit
b3045439b7c0
Source last updated
Oct 21, 2026
Last synchronized
Oct 21, 2026
Publication status
published
Publication history
  • Oct 21, 2026, 8:31 PM: new → published (ingestion) — Backed by an official breaking-change/migration guide.
AI explanationAI-generated · grounded in cited sources
AI explanations are not configured
Set AI_PROVIDER (for example to openai-compatible with a local Ollama or LM Studio endpoint) to enable grounded explanations. Everything else on this page works without an AI provider.
Was this useful?