Parent
#89
What to build
The flat rectangle from ticket 05 becomes a real colour field: hue across, saturation down, so the colour under the marker is the colour the light will be.
It is painted from a texture computed once in Rust, not from a gradient, and the reason is not a preference.
iced's gradients cannot draw this correctly. Both the quad and the triangle gradient shaders interpolate with smoothstep rather than linearly. smoothstep(t) = 3t^2 - 2t^3 departs from t by up to 9.6% of the segment length. On the saturation axis that is a ten-point error - the field would show 11.5% where the marker claims 21%. On a hue ramp built from the maximum of seven stops it is about 5.8 degrees, with wide plateaus of pure red and green and compressed transitions between them. The marker would sit on a different colour from the one it names, which disqualifies gradients for a colour picker rather than merely degrading them.
A wgpu shader would be exact but is wgpu-only, and iced's default features include the tiny-skia software fallback. On a machine without a usable adapter - remote desktop, a VM, an old GPU - the field would render as nothing. For an application made entirely of these widgets that is not an acceptable hole.
So: one texture, computed exactly, drawn scaled, correct on every backend.
Acceptance criteria
Testing
Red first at S5: the generator sampled at known points. Top-left is white, the full-saturation row matches the pure hues, the hue-zero column is red. Expected values come from the HSV definition, not from the generator's own arithmetic.
Then confirm by eye against the real Home Assistant instance, because "the marker sits on the colour it names" is the actual requirement and no unit test asserts it.
Blocked by
Parent
#89
What to build
The flat rectangle from ticket 05 becomes a real colour field: hue across, saturation down, so the colour under the marker is the colour the light will be.
It is painted from a texture computed once in Rust, not from a gradient, and the reason is not a preference.
iced's gradients cannot draw this correctly. Both the quad and the triangle gradient shaders interpolate with
smoothsteprather than linearly.smoothstep(t) = 3t^2 - 2t^3departs fromtby up to 9.6% of the segment length. On the saturation axis that is a ten-point error - the field would show 11.5% where the marker claims 21%. On a hue ramp built from the maximum of seven stops it is about 5.8 degrees, with wide plateaus of pure red and green and compressed transitions between them. The marker would sit on a different colour from the one it names, which disqualifies gradients for a colour picker rather than merely degrading them.A wgpu shader would be exact but is wgpu-only, and iced's default features include the
tiny-skiasoftware fallback. On a machine without a usable adapter - remote desktop, a VM, an old GPU - the field would render as nothing. For an application made entirely of these widgets that is not an acceptable hole.So: one texture, computed exactly, drawn scaled, correct on every backend.
Acceptance criteria
Testing
Red first at S5: the generator sampled at known points. Top-left is white, the full-saturation row matches the pure hues, the hue-zero column is red. Expected values come from the HSV definition, not from the generator's own arithmetic.
Then confirm by eye against the real Home Assistant instance, because "the marker sits on the colour it names" is the actual requirement and no unit test asserts it.
Blocked by