2.0 KiB
Parity harness
Renders every :demo screen on the native (SDL/Skia, Kotlin/Native) stack
and on the JVM upstream-Compose stack from the same commonMain
composables, then pixel-diffs them per screen. It's a regression net: a screen
whose difference jumps far above its usual level is a port bug (missing
content, wrong shape/colour, broken clip). Several of this project's renderer
regressions would have surfaced here.
python scripts/parity/parity.py # all screens (builds first)
python scripts/parity/parity.py Buttons Shapes # a subset
python scripts/parity/parity.py --no-build # reuse the last renders
python scripts/parity/parity.py --gpu=sdl3 # native renderer (default sdl3)
Output → build/parity/ (gitignored):
<pct>_<Name>_compare.png- native ∣ jvm ∣ amplified-diff, side by side<pct>_<Name>_diff.png- the amplified difference heatmap alonereport.txt- screens ranked by % differing
The <pct> prefix is zero-padded, so a plain file listing (or the report)
sorts worst-first.
Reading the result
Absolute % is not the metric - the ranking is. The two stacks use different default fonts, so text carries a steady baseline difference (in the heatmap, every text line shows a faint doubled ghost from slightly different line metrics). Buttons, cards, shapes, images should align (dark). So:
- doubled/ghosted text, dark shapes → normal font drift.
- a solid bright block, or a shape present on one side only → a real
regression. Open the
_compare.pngto see which stack is wrong.
Compare a screen's % against its neighbours and its own history: Buttons ~16%, Shapes ~14%, Colors ~4% are the healthy baseline (mostly text). A screen that reads 60% when text-light is the bug.
Requirements
- Windows for the native leg today (mingwX64 exe); the JVM leg is host-neutral.
- Pillow (
pip install pillow). - The JVM leg renders all screens headlessly via
ImageComposeScenein one process (:demo:run --args=--screenshot-all=…); native takes one exe launch per screen.