Blend geometry edge coverage in linear light

[ctate]

What

Anti-aliased fringes of opaque geometry — rounded rects, path fills and strokes (icons, charts, the checkbox mark) — now composite in linear light instead of sRGB space, which removes the dark rim sRGB blending grows on curved edges (the "still looks jagged despite AA" effect at 1x).

Scope discipline

• Glyph coverage keeps sRGB blending: linear blending visibly changes text weight (thin light-theme text, blooming dark-theme text), and the macOS text pipeline composites in sRGB — text pins are byte-identical before/after
• Translucent sources (washes, scrims, faded layers) keep sRGB blending everywhere, so overlay brightness is untouched
• The blend space is a required parameter on the coverage path (no default) and unit tests pin the split in both directions, so it can never silently invert

Mechanism

LUT-based conversion (existing 256-entry decode table + a new 4096-entry encode table, ≤1 level vs exact) with an opaque-source fast path: interiors and washes never pay conversion. Fully covered pixels are bit-identical; the supersampled shape-fidelity test passes unchanged (it pins coverage, which is blend-space-invariant).

Verification

• Shape goldens re-pinned from actual output with pixel review (diffs confined to corners/curves; e.g. the markdown fixture moved 728 pixels with max delta 1, zero in text)
• Text-only pins unchanged; whole-frame census shows zero changed text pixels in either scheme
• Full suite, validate, seven smokes, examples battery green; render budgets hold (deltas within run noise)

Note: the committed docs component-preview images render through these emitters and will show the old fringes until regenerated — follow-up, no CI check pins them.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
native-sdk	Ready	Preview, Comment	Jul 10, 2026 1:00pm