text.MultiFace causes nil *FontSource panic in GPU GlyphMask path on DrawString

[unxed]

Summary

Using text.NewMultiFace with a primary font + fallback fonts leads to a nil pointer dereference inside the GPU text path when DrawString is called.

The panic happens on the render thread:

runtime error: invalid memory address or nil pointer dereference

github.com/gogpu/gg/text.(*FontSource).copyCheck
github.com/gogpu/gg/text.(*FontSource).Parsed
github.com/gogpu/gg/internal/gpu.(*GlyphMaskEngine).LayoutText
github.com/gogpu/gg/internal/gpu.(*GPURenderContext).DrawGlyphMaskText
github.com/gogpu/gg.(*Context).tryGPUGlyphMaskText
github.com/gogpu/gg.(*Context).DrawString

Environment

• gg v0.50.11
• gogpu v0.50.2
• Linux + Vulkan (Intel HD Graphics 520)
• Go 1.26

Reproduction

1. Load a primary monospace font (UbuntuMono-R.ttf).
2. Load one or more fallback fonts (Noto Sans CJK / Noto Color Emoji etc.).
3. Create text.NewMultiFace(primary, fallbacks...).
4. Set it on a gg.Context and call DrawString (any non-ASCII character is enough to trigger it in our case).

Using only the primary face works fine.
Metrics() and Advance() on the MultiFace also succeed — the nil appears only later inside the GPU GlyphMask engine.

Notes

• The same set of fonts works correctly when used through the X11 backend (via golang.org/x/image/font).
• A simple feature probe that only calls Metrics() / Advance() is not sufficient to detect the bad MultiFace.
• Current workaround on our side: always return the primary face for the gogpu backend and disable MultiFace.

Expected behaviour

text.MultiFace should be usable with the GPU text path the same way a single FontSource.Face is. A nil *FontSource should never reach Parsed / copyCheck.

[kolkov]

Root cause (investigated from gogpu session)

MultiFace.Source() returns nil by design (text/multi.go:142-146 — composite face, no single FontSource). GPU glyph mask path calls fontSource.Parsed() without nil check → panic.

3 affected locations in internal/gpu/glyph_mask_engine.go:

• LayoutText line 126-128
• LayoutTextAliased line 184-186
• LayoutShapedGlyphs line 239-241

All follow the same pattern:

fontSource := face.Source()        // nil for MultiFace
parsed := fontSource.Parsed()     // PANIC

Deeper issue: MultiFace delegates each rune to a fallback font via faceForRune(), but the GPU path receives the composite MultiFace and tries to extract a single FontSource. Per-glyph FontSource resolution is needed — each glyph should carry a reference to which face (primary or fallback) produced it.

[kolkov]

@unxed Partial fix in v0.50.15: nil guards added to all 4 GPU text locations (GlyphMask ×3, MSDF ×1). MultiFace now gracefully falls back to CPU rendering instead of panicking.

Full GPU support for MultiFace is planned via ADR-065 (per-font run architecture, Skia TextBlob pattern) — each font in the fallback chain will get its own GPU batch.

go get github.com/gogpu/gg@v0.50.15

With this version, MultiFace works without crashes. Text will render via CPU path until ADR-065 enables GPU rendering for composite faces.

[unxed]

Thanks for the nil guards in v0.50.15 — the panics are gone. However, for a terminal UI, falling back to the CPU does not solve the problem: rendering a 139×37 frame (~5,000 glyphs) takes 2.3–2.9 seconds, freezing the entire window. My gg benchmark shows DrawString taking ~83 µs for a single glyph, and batching a span into a single string does not help (10.05 ms vs. 9.94 ms for 120 glyphs) — the cost is essentially per-glyph.

The reason is that drawGlyphs in text/draw.go creates a new NewGlyphMaskRasterizer() for every DrawString call and re-rasterizes the glyph from its outlines every time — there is no cache of rasterized masks at all. For a UI where the same set of glyphs is redrawn every frame, this is the dominant cost. My request would be to cache the masks by (gid, ppem, subpixel phase, hinting) at the FontSource level.

And I confirm that ADR-065 should remain the priority: until MultiFace works on the GPU, the choice is essentially between “CJK renders, but the UI is unusable” and “the UI is fast, but CJK is rendered as tofu boxes.”