What happened?
The bloom Radius slider on Settings -> Display moves in whole pixels only, and so
does Color bleed -> Width. Neither carries a drag step, so there is no fine
adjustment on either.
Every other slider on the page is finer than its click step. Brightness steps 10 and
drags 1; gamma steps 0.1, drags 0.01 and shows one decimal place. DxuiSlider already
supports all of this through SetDragStep and SetDecimalPlaces. Bloom radius and
color bleed width simply do not use it.
Two consequences:
- The interesting values are not reachable. Halation on a period monitor works out
near 2.4 to 2.7 emulated pixels, and one scanline is two of those units, so half-unit
resolution is what the setting actually wants. 2.5 cannot be expressed at all.
- Most of the travel is wasted. The radius range is 1 to 10, and after the change to
emulated-pixel units the useful band is roughly 1 to 4. Seven of the ten stops sit
past anything anyone would pick, and the region people do care about has four.
I expected fractional values and a range concentrated where the useful settings are.
Steps to reproduce
- Settings -> Display.
- Drag the bloom Radius slider. It jumps 1, 2, 3 and so on, with nothing in between.
- Same for Color bleed -> Width.
- Compare with Gamma directly above, which drags in hundredths.
Suggested shape
- Give both sliders a
SetDragStep and a SetDecimalPlaces (1), matching gamma.
- Revisit the ranges now that the units are emulated pixels rather than output pixels.
Something like 0.5 to 6 for radius would put the whole span in the region that gets
used. The prefs clamp in GlobalUserPrefs.cpp is 0 to 10 and would want the same
review.
- The readout suffix is a fixed 56 dip field shared by every slider, so a value like
2.5 px fits but anything longer does not.
Related: the radius unit itself is still an open question. Framebuffer pixels are a
Casso rendering choice, where scanline heights are a property of the hardware. If the
unit changes, the range and step should be settled in the same pass rather than twice.
Emulated machine
Apple //e
Casso version
v1.22.0 x64 (2026-09-02)
Windows version
Windows 11 Pro 10.0.26200
What happened?
The bloom Radius slider on Settings -> Display moves in whole pixels only, and so
does Color bleed -> Width. Neither carries a drag step, so there is no fine
adjustment on either.
Every other slider on the page is finer than its click step. Brightness steps 10 and
drags 1; gamma steps 0.1, drags 0.01 and shows one decimal place.
DxuiSlideralreadysupports all of this through
SetDragStepandSetDecimalPlaces. Bloom radius andcolor bleed width simply do not use it.
Two consequences:
near 2.4 to 2.7 emulated pixels, and one scanline is two of those units, so half-unit
resolution is what the setting actually wants. 2.5 cannot be expressed at all.
emulated-pixel units the useful band is roughly 1 to 4. Seven of the ten stops sit
past anything anyone would pick, and the region people do care about has four.
I expected fractional values and a range concentrated where the useful settings are.
Steps to reproduce
Suggested shape
SetDragStepand aSetDecimalPlaces (1), matching gamma.Something like 0.5 to 6 for radius would put the whole span in the region that gets
used. The prefs clamp in
GlobalUserPrefs.cppis 0 to 10 and would want the samereview.
2.5 pxfits but anything longer does not.Related: the radius unit itself is still an open question. Framebuffer pixels are a
Casso rendering choice, where scanline heights are a property of the hardware. If the
unit changes, the range and step should be settled in the same pass rather than twice.
Emulated machine
Apple //e
Casso version
v1.22.0 x64 (2026-09-02)
Windows version
Windows 11 Pro 10.0.26200