Warren currently couples text measurement and atlas drawing to its built-in text backend. Could we add an optional per-mount createTextRenderer factory so applications can keep their existing text JSX while supplying both metrics and GPU drawing?
System
Warren would retain layout, boxes, clipping, painter order, render passes and device ownership. The application backend would implement synchronous measure, frame-level prepare, per-run draw into a borrowed native pass, and dispose before device teardown.
Our motivation is using @pmndrs/glyph with Slug and TypeGPU. The extension itself would remain generic and add no text-library dependency.
Change
| Element | Today | After |
|---|---|---|
| UI mount and layout | Built-in text metrics | Optional per-mount factory and matching metrics |
| Warren renderer | Built-in atlas draws | Optional text draws interleaved with Warren's quads |
Do
- Add an optional text-backend factory to window and view mounts.
- Route existing text nodes through the supplied metrics and GPU backend.
- Preserve ancestor clipping, paint order and resource ownership; retain the built-in default.
- Document the native adapter contract and test ordering, clipping, disposal and failure recovery.
Risks
- Electrobun's native device/pass implement part of WebGPU. Libraries expecting complete browser WebGPU interfaces still need an application compatibility adapter.
- Text metrics can change layout; the same backend must measure and draw. Automatic window DPI sizing belongs to the separate #584 proposal.
Evidence
The current layout and renderer select built-in text directly. A local text-only prototype renders unchanged Warren JSX through Glyph/Slug and verifies retained updates, removal, clipping and painter order at 1×, 1.25× and 2× on macOS.
Unknowns
Is this four-method per-mount contract an extension point Warren would accept? Windows and Linux native text-backend integration have not been verified.
Activity
0No activity yet.