Upgrade to Taffy main (Grid: min-contribution optimizations + floor AvailableSpace at 0)

[nicoburns]

Summary

• taffy → git 9fa4b458f1a797b93cb2380f1e47c05d02a4fce3 (Grid: skip contribution measurement when no spanned track can receive it taffy#1177). Taffy's grid intrinsic track sizing no longer measures an item's min-/max-content contribution when none of its spanned tracks can receive it (matches Blink). On Wikipedia's Vector skin (grid-template-columns: 12.25rem minmax(0, 1fr)) the old behaviour measured the whole article under MinContent, which line-broke ~880 inline layouts at width 0 and then threw the result away.
• compute_inline_layout_inner: the definite available size handed to Parley is clamped at 0 after subtracting margins / content-box insets, so a 0-width container with margined children no longer produces Definite(-17.0)-style available widths (they only occurred inside the discarded pass above, but negative available width is never meaningful):

  .map_definite_value(|size| {
      (size.maybe_clamp(min, max) - content_box_inset.axis_sum()).max(0.0)
  })

Obama article, headless resolve() at 1280px (examples/obama_bench from #832's branch, 3 runs each, medians):

	first layout	relayout	heap after layout	heap peak
main	266–270 ms	145–151 ms	77.5 MB	157.3 MB
this PR	235–237 ms	119–121 ms	54.4 MB	110.9 MB

Zero-width break_lines passes 916 → 3, root height unchanged. blitz-dom/blitz-html tests and workspace clippy pass.

Link to Devin session: https://dioxus.staging.devinenterprise.com/sessions/3a0b8cc210c041d8955c841fb2a76a8e
Open in Devin Desktop: https://dioxus.staging.devinenterprise.com/desktop/session/3a0b8cc210c041d8955c841fb2a76a8e?variant=devin-insiders
Requested by: @nicoburns

WPT results

Subtests: 4 newly passing, 0 newly failing (net +4).

Full diff (4 changed tests)

+ FAIL => PASS    [1/1]  +1  css/CSS2/floats/floats-wrap-bfc-with-margin-004.html
+ FAIL => PASS    [1/1]  +1  css/CSS2/floats/floats-wrap-bfc-with-margin-005.html
+ FAIL => PASS  [24/24]  +1  css/css-grid/parsing/grid-template-columns-computed-implicit-track.html
+ FAIL => PASS  [24/24]  +1  css/css-grid/parsing/grid-template-rows-computed-implicit-track.html

_{Generated by the WPT workflow.}

[staging-devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR that start with 'DevinAI' or '@devin'.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[yinnho]

Just mirrored your new taffy pin in aginxbrowser (our taffy-based render stack — no stylo/parley, custom css+layout+paint on top of taffy leaves) and ran an A/B on the two revs. Your Wikipedia numbers reproduced in shape on a synthetic stand-in: en.wikipedia is unreachable from my network, so I built a 3000-paragraph page around the template from your PR description.

Release binaries, loopback, median of 5, spread under 1%:

• definite-width grid-template-columns: 12.25rem minmax(0,1fr): 28.7s → 18.1s (-37%)
• same grid inside an inline-block wrapper (intrinsic sizing fully engaged): 66.0s → 34.0s (-48%)

All three page shapes render pixel-identical across the upgrade (1,024,000 px compared, zero diffs), so for us it was pure wasted work being removed, no output change. Test suite count identical before/after.

One attribution note for anyone else tracking the win: the rev jump 864b4fd → 1b918ba is 39 commits, and on our side #1119 (avoid unnecessary flex item min-content measurement) looks like it contributes at least as much as #1177 — our inline runs are flex rows, so every paragraph was eating a redundant min-content measure even on the definite-width variant. The grid fix is what makes the indefinite case collapse, though.

Thanks for the detailed PR body — the "916 zero-width break_lines passes" line is what told me exactly which shape to build.

[nicoburns]

Not sure what your setup is or what you were measuring, but 20s still seems very slow if it's a realistic page!

[yinnho]

Fair pushback — the framing was mine to fix, and I should have labeled what the seconds covered. Those numbers were our whole /screenshot pipeline end-to-end on loopback (HTML parse → style → taffy layout → paint → PNG encode), not layout-only, on a page built specifically to maximize the redundant-measurement path (I took the shape from your "916 zero-width break_lines passes" line). So the absolutes were a stress amplification, never "taffy time".

I rebuilt the pages for a proper breakdown (so absolutes won't tie to my earlier 28.7→18.1 / 66→34 numbers — different generator, same stress idea), same harness for every row this time: release build, new rev, loopback, 1024x1000 viewport, median of 3:

• realistic article-shaped page (~280 elements, one small grid): 0.91s end-to-end, and that includes per-request browser+isolate setup
• the same 3000 paragraphs as plain block flow, no grid: 6.0s
• 3000 paragraphs as direct grid children, definite tracks: 8.7s
• same 3000 direct children inside an inline-block wrapper (intrinsic sizing fully engaged): 12.8s

So to your point directly: no, a realistic page is not 20s here — it's under a second through the whole pipeline. The seconds all live in the deliberate stress shape. And the breakdown says most of even that is ours, not yours: plain block-flow of 3000 paragraphs costs 6s (~2ms/paragraph, and a profiler pass points at our text shaping and glyph paint, not layout math). Grid on top adds ~2.7s at 3000 items with definite tracks and ~6.8s with intrinsic sizing engaged — so there's still measurable grid work left at that scale, worth a closer profile on our side before I claim where it sits between track math and our leaf measurement closures. Either way the upgrade was pure win for us: zero pixel diffs, and the intrinsic case roughly halved.