Render PRK.Client windows through retained backing surfaces
Replace repeated flattening of movable UI windows into the monolithic CPU surface with bounded retained per-window GPU textures and quad composition. Window movement must reuse existing rendered pixels and change composition position rather than repainting the complete window subtree. Content damage should update only affected backing-surface regions. Preserve window z-order, transparency, overlap, occlusion, UI scaling, resize behavior, and input semantics. Acceptance criteria: - Dragging an unchanged window does not repaint its chrome or descendant controls. - Content changes update only damaged regions in that window's backing surface. - Old and new drag locations reveal and compose overlapping UI correctly. - Backing surfaces are bounded by an explicit native-memory budget and safely released. - Pixel/incremental rendering and window interaction regression tests pass. - A drag-heavy before/after profile shows a substantial reduction in UI paint occupancy and improved frame pacing. Architecture decision: - A CPU-backed retained-window prototype was implemented and profiled, then discarded before commit. It increased drag UI-paint occupancy from 50.9% to 79.0% because every move still copied the large window bitmap into the monolithic CPU surface. - Retention must cross the CPU/GPU boundary: window content is uploaded only when damaged, while movement and z-order are represented by GPU quad composition.
Checklist
1 of 5 complete- Design retained-window composition and damage ownership around existing GuiSurface/GuiSkiaRenderer
- Implement bounded per-window backing surfaces and movement reuse
- Add overlap, movement, damage, scaling, resize, and disposal regression tests
- Build client and run relevant UI suites
- Capture drag-heavy in-game profile and compare against baseline
- Area
- Project Rubi-Ka
- Project
- engines
- Kind
- Feature
- Priority
- High
- Task ID
tsk_sxa6b64a9p- Updated