Give a length with no share in it its own type again
`UiScalar` was `Len` without the `leftover` weight, which is the separation canonical `main` already had as `Len` beside `LayoutLen` and this branch collapsed. It is needed back for the queued clamp: a cap may not contain a share, because a cap has to read the report a rule otherwise makes moot, and a share puts the container's division into the same equation -- two self-consistent assignments, which is the multiple-fixed-point failure generated seed 13 punished for orthogonal sizing. `min(report, cap)` is not a `LayoutLen` either: it is a sum of parts, and the smaller of two of them is not one. So `UiScalar` is `Len`, what was `Len` is `LayoutLen`, and the two say in their docs which is which: a `Len` is pixels plus a fraction of a box -- a position being the length from the box's start, which is why a span is two of them -- and a `LayoutLen` is a `Len` plus a claim only a container dividing its room can answer. `From<Len> for LayoutLen` is the one-way step between them. Names only; the shader's `UiScalar` is renamed with them. Checked: fmt, clippy, 105 tests, and `tabs`, `minimal`, `view`, `text` and `random` byte-identical at 1920x1200. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
1 parent
4f5e27cba9
commit
a8898aaa54
27 files changed
+218
-202
No files matched your search
@@ -49,16 +49,16 @@ struct RawSpan {
|
||||
end: RawScalar,
|
||||
}
|
||||
|
||||
fn scalar_of(raw: RawScalar) -> UiScalar {
|
||||
return UiScalar(f32(raw.rel) * REL_STEP, f32(raw.px) * PX_STEP);
|
||||
fn scalar_of(raw: RawScalar) -> Len {
|
||||
return Len(f32(raw.rel) * REL_STEP, f32(raw.px) * PX_STEP);
|
||||
}
|
||||
|
||||
fn span_of(raw: RawSpan) -> UiSpan {
|
||||
return UiSpan(scalar_of(raw.start), scalar_of(raw.end));
|
||||
}
|
||||
|
||||
fn scalar_of_pair(raw: vec2<i32>) -> UiScalar {
|
||||
return UiScalar(f32(raw.x) * REL_STEP, f32(raw.y) * PX_STEP);
|
||||
fn scalar_of_pair(raw: vec2<i32>) -> Len {
|
||||
return Len(f32(raw.x) * REL_STEP, f32(raw.y) * PX_STEP);
|
||||
}
|
||||
|
||||
struct Region {
|
||||
@@ -72,12 +72,12 @@ const MOVE_NONE: u32 = 4294967295u;
|
||||
// resolve a deep one the same way.
|
||||
const CHAIN_LIMIT: u32 = 64u;
|
||||
|
||||
// The same expression `UiScalar::within` uses, in floats rather than on the
|
||||
// The same expression `Len::within` uses, in floats rather than on the
|
||||
// CPU's grid: a move is resolved here so that scrolling a subtree writes one
|
||||
// entry instead of walking it. What has to hold is that this agrees with
|
||||
// itself frame to frame, not that it matches the CPU to the last bit.
|
||||
fn scalar_within(s: UiScalar, p: UiSpan) -> UiScalar {
|
||||
return UiScalar(
|
||||
fn scalar_within(s: Len, p: UiSpan) -> Len {
|
||||
return Len(
|
||||
p.start.rel + (p.end.rel - p.start.rel) * s.rel,
|
||||
s.px + (p.start.px + (p.end.px - p.start.px) * s.rel),
|
||||
);
|
||||
@@ -102,11 +102,11 @@ fn resolve_move(idx: u32, local: Region) -> Region {
|
||||
}
|
||||
|
||||
struct UiSpan {
|
||||
start: UiScalar,
|
||||
end: UiScalar,
|
||||
start: Len,
|
||||
end: Len,
|
||||
}
|
||||
|
||||
struct UiScalar {
|
||||
struct Len {
|
||||
rel: f32,
|
||||
px: f32,
|
||||
}
|
||||
|
||||
Reference in new issue
Block a user