Support

[AgentNemo00]

Some question about the support of the lib. It may be from someone with less experience on UI topics but I would love a deep knowledge transition.

Do you guys are supporting serialization for server driven UI ?

Do you guys plan to support Frame Compositor (Module-owned Rendering) ?

[kolkov]

@AgentNemo00 — quick follow-up to your two original questions, since both finally have proper answers.

Frame Compositor (Module-owned Rendering) — yes, building it. Dedicated standalone library at https://github.com/gogpu/compose, with the architectural overview, multi-window comparison, Module Federation comparison, and roadmap in #177 RFC: compose — multi-process composition library for Go. The first user is your Magic Mirror Go rewrite — the practical thread (offscreen rendering, render-loop pattern, IPC bandwidth, calibration questions for your Pi setup) lives at gogpu/ui#75.

Server-Driven UI — deliberately not now. Honest reasoning + conditional commitment in the SDUI section of #177. Short version: nobody (including you, with the pixel-streaming compose pattern) needs it as a hard requirement right now, and we want to avoid designing a large subsystem against hypothetical demand. If real friction emerges later, please open a separate discussion and walk us through the scenario.

Related orthogonal track: #167 RFC: Multi-Window Support for gogpu is in-process multi-window (one process, N windows, shared GPU Device) — distinct from compose which is multi-process. The two are layers, not alternatives.

Thank you for raising both questions back in April. The Frame Compositor half drove an architectural commitment we are now executing on.

[AgentNemo00]

I'm fine with the answer given. Feel free to close.