Render udpates

apps/RenderCadenceCompositor/README.md

@@ -44,7 +44,8 @@ Included now:
 - app-owned display/render layer model for shader build readiness
 - app-owned submission of a completed shader artifact
 - render-thread-owned runtime render scene for ready shader layers
-- render-thread-only GL commit once the artifact is ready
+- shared-context GL prepare worker for runtime shader program compile/link
+- render-thread-only GL program swap once a prepared program is ready
 - manifest-driven stateless single-pass shader packages
 - HTTP shader list populated from supported stateless single-pass shader packages
 - default float, vec2, color, boolean, enum, and trigger parameters
@@ -197,7 +198,7 @@ Healthy first-run signs:
 
 On startup the app begins compiling the selected shader package on a background thread owned by the app orchestration layer. The default is `shaders/happy-accident`.
 
-The render thread keeps drawing the simple motion renderer while Slang compiles. It does not choose packages, launch Slang, or track build lifecycle. It only receives a completed shader artifact and attempts the OpenGL shader compile/link at a frame boundary. If either the Slang build or GL commit fails, the app keeps rendering the simple motion fallback.
+The render thread keeps drawing the simple motion renderer while Slang compiles. It does not choose packages, launch Slang, or track build lifecycle. Once a completed shader artifact is published, the render-thread-owned runtime scene queues changed layers to a shared-context GL prepare worker. That worker compiles/links runtime shader programs off the cadence thread. The render thread only swaps in an already-prepared GL program at a frame boundary. If either the Slang build or GL preparation fails, the app keeps rendering the current renderer or simple motion fallback.
 
 Current runtime shader support is deliberately limited to stateless single-pass packages:
 
@@ -213,7 +214,7 @@ The `/api/state` shader list uses the same support rules as runtime shader compi
 
 Runtime shaders are exposed through `RuntimeLayerModel` as display layers with manifest parameter defaults. The model also records whether each layer has a render-ready artifact. Add/remove POST controls mutate this app-owned model and may start background shader builds.
 
-When a layer becomes render-ready, the app publishes the ready render-layer snapshot to the render thread. The render thread owns the GL-side `RuntimeRenderScene`, diffs that snapshot at a frame boundary, commits/removes GL programs, and renders the ready layers in order. Current layer rendering is still deliberately simple: each stateless full-frame shader draws to the output target using fallback source textures until proper layer-input texture handoff is designed.
+When a layer becomes render-ready, the app publishes the ready render-layer snapshot to the render thread. The render thread owns the GL-side `RuntimeRenderScene`, diffs that snapshot at a frame boundary, queues new or changed programs to the shared-context prepare worker, swaps in prepared programs when available, removes obsolete GL programs, and renders ready layers in order. Current layer rendering is still deliberately simple: each stateless full-frame shader draws to the output target using fallback source textures until proper layer-input texture handoff is designed.
 
 Successful handoff signs:
 
@@ -264,6 +265,7 @@ This app keeps the same core behavior but splits it into modules that can grow:
 - `platform/`: COM/Win32/hidden GL context support
 - `render/`: cadence, simple rendering, PBO readback
 - `render/RuntimeRenderScene`: render-thread-owned GL scene for ready runtime shader layers
+- `render/RuntimeShaderPrepareWorker`: shared-context runtime shader program compile/link worker
 - `runtime/`: app-owned shader layer readiness model, runtime Slang build bridge, and completed artifact handoff
 - `control/`: local HTTP API edge and runtime-state JSON presentation
 - `json/`: compact JSON serialization helpers