Val calc support by ickshonpe · Pull Request #26409 · bevyengine/bevy

ickshonpe · 2026-11-02T15:00:07Z

Objective

Add support for more operations on Vals:

addition and subtraction of incompatible units
min and max
clamp

Solution

There seems to be three main workable approaches but all of them have some drawbacks and compromises:

(used in this PR) A 16-byte enum with a Calc variant that wraps an Arc containing the expression tree. Expressions with up to three values can be packed into the Val struct.
(used by Stylo) An 8-byte union type that is either an aligned pointer to an expression on the heap or a unit tag and f32 length value. No longer an enum.
An 8-byte enum with a Calc variant that wraps an id into some sort of global expression arena.

With all three Val has to be non-copy. I think don't think copyable is viables, all the alternatives I considered give up composability and/or leak.

This PR implements approach 1, using a 16-byte enum. I'm not convinced it's the best approach, but I'm not sure that there is a best approach. It seemed the simplest route for the initial PR, but then I got carried away with all the expression reduction and packing stuff.

Testing

Showcase

AI Disclosure

Used lots of AI

Remove CalcOps::Scale and push scales down to the leaves immediately, so repeated *= and /= no longer deepen the tree. Negative scales swap Min and Max, and turn Clamp into Min/Max to preserve the crossed bounds behavior. Replace stale Calc:: names with CalcOps::, rebuild the corrupted calc tests, and clone Vals in the crates that still relied on Val being Copy. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…nit types when packing Vals.

Up to three terms with distinct units are stored inline as a `ValUnitSet` bitmask plus `[f32; 3]`, keeping `Val` at 16 bytes and making `px + percent`, `min` and `max` of leaves allocation-free. `+`, `-`, `min` and `max` fold same-unit terms, keep terms in unit order, and fall back to `Calc` for anything longer or nested. `Sum` equality ignores zero terms, `Min`/`Max` swap under negation, and all three interpolate term-wise. `LayoutCalc` now holds a `Val` so the layout path resolves them like `Calc`. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Stores `[min, value, max]` as `[ValUnit; 3]` and `[f32; 3]`, keeping `Val` at 16 bytes. `Val::clamp` builds it when all three operands are unit values and falls back to `CalcOp::Clamp` otherwise. Negation swaps the bounds so it stays a `Clamp`, and it interpolates slot-wise. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Since they now take &self, the convention is to use a `to_` prefix.

`Val::to_physical` maps every leaf except percent to physical `Px` when the taffy style is rebuilt, folding through the `Val` operators so most expressions collapse to a single length or an inline sum of a length and a percentage. `LayoutCalc` then holds only that `Val` and resolves against taffy's basis alone, so it no longer stores a `LayoutContext`. `Val::clamp` now folds three same-unit operands. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Nothing in the layout pass reads it any more, since calc expressions are resolved to physical pixels when the taffy style is rebuilt. It is re-exported from `layout` so `bevy_ui::LayoutContext` is unchanged. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

`-clamp(lo, v, hi)` is `min(-lo, max(-v, -hi))`, which is the clamp with its bounds swapped only when `lo <= hi`. Same-unit bounds are ordered by construction, since inverted ones fold to the minimum, so they swap; mixed-unit bounds can invert at some bases, so they fall back to the exact `Calc` form as `CalcOp::scale` already does. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

serde only implements `Serialize` and `Deserialize` for `Arc<T>` behind its `rc` feature, which nothing in the graph enables, so the derived impls on `Calc` did not compile with the `serialize` feature. Delegating to the inner `CalcOp` fixes that and keeps the sharing out of the serialized form. Adds a ron round-trip test for expressions. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

The swapped-bounds shortcut assumed same-unit bounds are ordered, which only holds for clamps built through `Val::clamp`. A `Val::Clamp` built directly with `min > max` resolves to its minimum, so negating it must give the negated minimum; check the ordering instead of assuming it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Moved the `Val` types and implementation from `geometry` into `val`.

Every calc pointer in a `TaffyStyle` points into one of the `Arc<PercentageCalc>`s stored alongside it, so `resolve_calc` can dereference the pointer taffy hands back. That removes the per-layout subtree walk, the pointer map and the `resolve_calc` closure plumbing. To keep that sound, `TaffyStyle` loses `DerefMut` and its fields become crate-private, so nothing outside the layout module can store a pointer in a style, and `MeasureArgs` is `#[non_exhaustive]` so it can only be built by the layout system. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Used it in `convert` to resolve leaf values.

… More doc comments and cleanup.

…to also use ValContext.

Kees-van-Beilen · 2026-11-02T16:15:18Z

Hey from what I have seen from your current implementation is that you add Calc to the value enum.
Would it be possible to instead to create a ComputableVal trait or similar. As currently this change would be breaking as the Val enum would no longer be copyable. This way more complex variants of Val can be stored outside of the Val struct

ickshonpe · 2026-11-02T20:14:46Z

Hey from what I have seen from your current implementation is that you add Calc to the value enum. Would it be possible to instead to create a ComputableVal trait or similar. As currently this change would be breaking as the Val enum would no longer be copyable. This way more complex variants of Val can be stored outside of the Val struct

I think breaking changes are probably unavoidable. The question with a ComputableVal trait is, what would the type of Node::width be? If it stays Val, where does px(10) - percent(50) go? We could store expressions in a global table or something, but how are they composed and how do we ensure that they don't leak? I'd like to keep Val copyable, but I wasn't able to come up with any solutions that satisfy all these questions.

Kees-van-Beilen · 2026-11-02T20:35:22Z

Yeah you are right. I would prefer like a ComplexerVal, with an from Val impl. That would require non bsn code to add into everywhere. Either way indeed old code would break.

The only non breaking version I can think of would be:

promote Node to a special genericable struct (so that complexer val is opt in) So like Node<ValType: RestrictedComputableVal> with the restriction that all RestrictedComputableVal need to be of the same size (and inlcude a discriminator) (or maybe not.) Then at a later stage the type can be erased and more restriction would apply

But maybe indeed computable vals can be opt-in via generics, it would be a lot more rewritting requiring AnyOf in systems. But then all changes can also be made incrementally

ickshonpe · 2026-11-02T20:46:00Z

Yeah you are right. I would prefer like a ComplexerVal, with an from Val impl. That would require non bsn code to add into everywhere. Either way indeed old code would break.

The only non breaking version I can think of would be:

promote Node to a special genericable struct (so that complexer val is opt in) So like Node<ValType: RestrictedComputableVal> with the restriction that all RestrictedComputableVal need to be of the same size (and inlcude a discriminator) (or maybe not.) Then at a later stage the type can be erased and more restriction would apply

But maybe indeed computable vals can be opt-in via generics, it would be a lot more rewritting requiring AnyOf in systems. But then all changes can also be made incrementally

I thought about doing something similar to this in the past, but it was before required components. I think all the widgets that #[require(Node)] probably makes any sort of generic Node component unviable.

ickshonpe · 2026-11-02T20:48:08Z

Another thing we could try is a feature gate, but I reckon it would be prohibitively complicated and fragile. Both internally and for 3rd party crates.

Kees-van-Beilen · 2026-11-02T21:06:56Z

You could always have an optional ComputableValLayerNode then it's an opt in for everyone, right?
add the user level if you want complexer vals then you can additionally use that component.

Also the require api could be updated to an #[require_any_of(Node<Val>, Node<ComplexVal>)], defaulting to Node<Val>. I think this option actually suits bests

ickshonpe and others added 30 commits November 1, 2026 08:30

Draft the structure for the calc impl

6c8ca56

calc module

251a64e

Calc as a tree

a873e94

Renamed CalOps to CalcOp

aa12725

Added min, max and clamp heleprs to Val.

b6ba44d

Changed Calc to use an Arc instead of a Box

406a3ee

Added some minimal doc comments, make Calc inner value pub (crate).

cba4c35

Added ValUnit discriminator enum, to be used for representing Val u…

c45d571

…nit types when packing Vals.

Added a check that val units count is <= 8.

345a088

Renamed Val methods in convert.

021e1b5

Since they now take &self, the convention is to use a `to_` prefix.

Use bevy_platform::sync::Arc instead of std::sync::Arc.

5d3136b

Test that negating min and max negates their results

d573e85

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Added failing clamp tests

faf842c

Renamed LayoutCalc to PercentageCalc

067eedb

Updated doc comments for convert

1d4afb0

Renamed LayoutContext to ValContext.

084ca8a

Moved ValContext into the calc module and added doc comments.

a2aaed6

Renamed calc module to val.

41c25fb

Moved the `Val` types and implementation from `geometry` into `val`.

Fix unbalanced backtick in to_physical doc comment

e5b3d43

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Added a resolve method to ValUnit.

3b6a72e

Used it in `convert` to resolve leaf values.

Renamings for clarity: Terms to Operands, TermOp to ReduceUp.…

3b74bdc

… More doc comments and cleanup.

Updated BorderRadius, UiPosition, Val2, UiTransform and CornerRadius …

2b176ab

…to also use ValContext.

ickshonpe added A-UI Graphical user interfaces, styles, layouts, and widgets D-Complex Quite challenging from either a design or technical perspective. Ask for help! labels Nov 2, 2026

github-project-automation Bot added this to UI Nov 2, 2026

github-project-automation Bot moved this to Needs SME Triage in UI Nov 2, 2026

Update and clean up doc comments some more.

a684051

ickshonpe added 10 commits November 2, 2026 16:23

More doc comments

5060720

More doc comments.

8cd29d2

More doc comments

b4822dc

More Val doc comments

c88416f

More doc comments

89b22f3

ValUnitSet doc comments

86ce06e

Renamed ValUnitSet::slot to index, updated doc comments.

b978b6a

Added doc test doing interpolation between two sums.

70ef450

More doc comments for new Val methods.

673091d

More doc comment edits.

19277ed

ickshonpe mentioned this pull request Nov 2, 2026

Val reorganisation #26415

Open

Navigation Menu

Repository navigation

Val calc support - #26409

Val calc support#26409
ickshonpe wants to merge 47 commits into
bevyengine:mainfrom
ickshonpe:arc_calc

ickshonpe commented Nov 2, 2026 •

edited

Loading

Uh oh!

Kees-van-Beilen commented Nov 2, 2026

Uh oh!

ickshonpe commented Nov 2, 2026 •

edited

Loading

Uh oh!

Kees-van-Beilen commented Nov 2, 2026

Uh oh!

ickshonpe commented Nov 2, 2026

Uh oh!

ickshonpe commented Nov 2, 2026

Uh oh!

Kees-van-Beilen commented Nov 2, 2026 •

edited

Loading

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

ickshonpe commented Nov 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Objective

Solution

Testing

Showcase

AI Disclosure

Uh oh!

Kees-van-Beilen commented Nov 2, 2026

Uh oh!

ickshonpe commented Nov 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kees-van-Beilen commented Nov 2, 2026

Uh oh!

ickshonpe commented Nov 2, 2026

Uh oh!

ickshonpe commented Nov 2, 2026

Uh oh!

Kees-van-Beilen commented Nov 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ickshonpe commented Nov 2, 2026 •

edited

Loading

ickshonpe commented Nov 2, 2026 •

edited

Loading

Kees-van-Beilen commented Nov 2, 2026 •

edited

Loading