iris-aiandClaude Opus 5 45a717695b Compose a box down its chain once, not once a level
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>
2026-09-16 21:30:45 -04:00
2026-01-05 17:01:09 -05:00
2025-11-17 16:08:29 -05:00
2026-01-29 16:39:19 -05:00
2026-09-13 00:24:29 -04:00

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:

  1. does what I want it to (text, images, video, animations)
  2. very easy to use ignoring ergonomic ref counting
  3. 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

S
Description
No description provided
Readme
4.1 MiB
0 Stars 1 Watchers 0 Forks
Languages
Rust 96.3%
Shell 2.1%
WGSL 1.6%