Sets supports2x: true in the manifest and threads a single `scale`
value (2 if canvas.is2x() else 1, computed once in main()) through
every size-based constant in the file -- the album art decode size,
art slot, scanline spacing/thickness, corner tick size/thickness,
jitter shift magnitude, RGB-split band positions/heights, text column
width, progress bar, and separator line -- rather than hardcoding
separate 1x/2x numbers. Tick-based timing (durations, hold ticks) is
deliberately left unscaled, since those are real time, not space.
This is what actually makes 2x worth something for the album art
specifically: decoding at ART_SIZE * scale pulls genuinely more detail
from the source JPEG (fetched live from the station, usually far higher
resolution than even a doubled target) rather than just letting pixlet
passively pixel-double the final composited image, which was confirmed
empirically to add zero real detail.
GLITCH_STATE_POOL's hand-tuned 1x pixel values are scaled at the point
of use rather than given a separate 2x table: doubling every term in an
already-verified non-overlapping, safe-margin relationship can't change
its sign or introduce a new overlap/exposure that wasn't already ruled
out at 1x.
Title/artist Text widgets are now explicitly pinned to font="tb-8"
(pixlet's own 1x default) rather than left unspecified -- otherwise
they'd have silently picked up pixlet's auto-upsized 2x default font
while every other line (explicitly "tom-thumb") stayed the same size,
an inconsistency this app's existing small-pixel-font identity doesn't
call for. (A render.Root delay halving was tried first, per pixlet's
own 2x-authoring docs, but that only makes sense when Marquee content
actually grows at 2x -- for lines that stay the same size by explicit
font choice, halving the delay would have overcorrected and made them
scroll too fast. Dropped once the real fix was pinning the font instead.)
Verified: 1x payload basically unchanged (296KB baseline -> 313KB,
comfortably under the 460KB Gen1 limit). 2x payload is much larger
(~950KB) since it's now genuinely encoding more real image detail, not
padding -- expected and accepted for the newer/higher-capacity hardware
2x targets, per explicit confirmation this isn't bound by the same
Gen1 buffer limit. Black-border safety reconfirmed at both resolutions
via an isolated jitter+bands-only render (scanlines/corner ticks
excluded, since they legitimately draw black pixels at the exact
corner coordinates sometimes as part of normal operation, which a naive
full-stack corner check can't distinguish from a real margin bug): 0
hits at both 1x and 2x.
poprhythm