Electrobun GPUWindow: add a first-class HUD/UI composition path

[devallibus]

Problem

The current Electrobun GpuWindow path has no first-class HUD/UI composition story. In practice that means native-mode examples have to fall back to window-title status, console alerts, or runtime-specific ad hoc overlays.

That is a real product gap, not just a documentation gap: a high-speed or action-oriented game needs a supported way to present status, targeting, prompts, and feedback without abandoning the GPU-native render path.

Why this matters

• It makes the GPU-native path feel materially less capable than the browser or BrowserWindow path.
• It forces each example or app to invent its own overlay strategy.
• It blocks a class of games that need persistent HUD, transient prompts, and readable mission/combat feedback.

Suggested scope

• Define and support one canonical HUD composition strategy for GpuWindow.
• Keep the solution renderer-agnostic at the gametau boundary where possible.
• Document the tradeoffs between candidate approaches rather than leaving each app to rediscover them.

Candidate directions

• Hybrid composition: browser/webview UI plus GPU-native render surface with explicit focus/input coordination
• Native overlay layer for text/widgets in the GPU path
• Texture-based HUD composition rendered into the GPU scene

Acceptance criteria

• There is one documented, supported HUD/UI path for GpuWindow apps.
• The approach covers persistent HUD plus transient alerts/prompts.
• Input/focus behavior is defined well enough that examples can share the same pattern.

Related

• [P2] Publish BrowserWindow vs GPUWindow capability matrix #105
• [Design] RenderAdapter interface for non-DOM rendering paths #117
• [Design] Non-DOM InputAdapter for GPUWindow keyboard/mouse events #118