Her audit of the course captures found a uniform 1px alpha-255 line
where trunk should draw 2.2 screen px. Live A/B bracket (20/1.5/1.1/
0.6 forced widths + draw_line-vs-draw_polyline control) localized the
cause: Godot's line rasterizer floors stroke widths below ~1.0 canvas
units to hairline — the _zs arithmetic was correct (1.4/3.75=0.373
round-trips exactly); the value died at the driver. Fix: zoom_
compensated_stroke_width() (the _zs divide maxf'd at 1.0) via a
_zs_stroke() wrapper on EVERY stroke-width site (course polyline,
skeleton chords, mouth-ring arcs, basin boundary, attractor outlines
— same latent class everywhere even where not yet visible); radius
args proven unaffected and left on _zs. Honest degradation direction
documented: at high zoom effective width grows rather than pinning.
Class question resolved with printed ground truth: the original
window is genuinely single-drawable-class (trunk course degenerate at
1 point); a confluence window confirms real multi-class rendering.
The drive now prints per-course class/width/effective-px tables every
run. New 14-test stroke-width suite (own file, line-cap split) pins
the exact floor-engagement numbers and the PR#195-shape effective-
width >= table-value invariant; revert-verified (floor drop -> 4
named failures). Full client suite 3942/3942; gdlint clean.
Tickets: T-1170
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
jpmschweitzerandClaude Fable 5
27fab8566a