Bryan's call, 2026-09-16, for correctness. `Moves` walked the move chain in `Len`, so every level's four multiplies landed back on the grid before the next started and the residue grew with the depth of the tree. `WideLen` carries a length through the walk on a grid twenty-four bits of a box and twenty-two of a pixel finer, and rounds once at the end. What it buys, measured rather than argued: `Holds::through`'s allowance for the two routes to a length drops from three half steps to two, and the whole of a box now maps back to a range one step wide rather than one step per level of nesting. One half step further is arithmetically available -- the `Holds` assertion is quiet there and the whole-box case becomes an exact identity -- and it is **not taken**, because shrinker seed 220 then lays out differently warm than cold. Too narrow is meant to cost a redraw and no more; there it re-breaks a wrapping text, whose reported width moves a `Branch` onto its other subtree. That is the unsettled-text family, and closing it is what would let this go lower. The note is in `through`. `Moves` now answers three questions instead of one, and they are different questions: `size_of` for how long a box is, which is what reads a box in pixels; `compose` for where both of its ends are, which is what compares two boxes; and `resolve`, unchanged, for the `Len` walk the vertex shader does again in floats. A length composes on its own in two multiplies a level rather than four, since where the parent sits falls out of the difference -- which is most of why this is not slower. Measured on the fixed-shape fixture, seed 1 depth 8, 500 frames of `many`, medians of 25 runs with all twenty-five work counters identical between the two: 1,880M instructions and 755M cycles against 1,908M and 760M. So it is free, and a little better on instructions. Three things were tried on the way and two kept: composing the length alone rather than both ends (-111M instructions), taking the pixel term's fraction on the ordinary grid so it stays in an `i64` (-2M instructions, -8M cycles), and skipping a parent that spans its own box, which **cost** 18M instructions and is not here -- the same verdict a short-circuit got in `UiSpan::within`. Checked: fmt, clippy, 83 suite tests, 17 core unit tests, the release oracle at 100 seeds and at 1000 seeds of depth 6, all fifteen shrinker cases at 400 seeds of depth 5, and `tabs`, `view`, `minimal`, `text` and `random` byte-identical at 1920x1200 against `d21a215`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
iris
My experimental attempt at a rust ui library (also my first ui library).
It's currently designed around using retained data structures (widgets), rather than diffing generated trees from data like xilem or iced. This is an experiment and I'm not sure if it's a good idea or not.
Examples are in examples, eg. cargo run --example tabs.
Goals, in general order:
- does what I want it to (text, images, video, animations)
- very easy to use ignoring ergonomic ref counting
- reasonably fast / efficient (a lot faster than electron, save battery life, try to beat iced and xilem)
dev details
not targeting web rn cause wanna use actual nice gpu features & entire point of this is to make desktop apps / not need a web browser
general ideas trynna use rn / experiment with:
- retained mode
- specifically designed around wgpu so there's no translation
- postfix functions for most things to prevent unreadable indentation (going very well)
- events can be done directly where you draw the widgets
- almost no macros in user code & actual LSP typechecking (variadic generics if you can hear me please save us)
- relative anchor + absolute offset coord system (+ "rest" / leftover during widget layout)
- single threaded ui & pass context around to make non async usage straightforward (pretty unsure about this)
- widgets store outside of the actual rendering so they can be moved around and swapped easily (unsure about this but seems to work good for now)
under heavy initial development so not gonna try to explain status, maybe check TODO for that; sizable chance it gets a rewrite once I know everything I need and what seems to work best
it's called iris because it's the structure around what you actually want to display and colorful