aiden/video-shader-toys
1
0
Fork 0
Code Issues Pull Requests Actions Releases 5 Wiki Activity

Phase 4 step 2a
All checks were successful
CI / React UI Build (push) Successful in 11s
Details
CI / Native Windows Build And Tests (push) Successful in 2m36s
Details
CI / Windows Release Package (push) Successful in 2m42s
Details

Browse Source
This commit is contained in:
Aiden
2026-05-11 17:26:24 +10:00
parent 539fcd3351
commit 0ec5a4cfed
7 changed files with 358 additions and 67 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
docs/PHASE_4_RENDER_THREAD_OWNERSHIP_DESIGN.md
View File

@@ -7,12 +7,12 @@ Phase 1 named the subsystems. Phase 2 added the typed event substrate. Phase 3 m
## Status
- Phase 4 design package: proposed.
- Phase 4 implementation: Step 1 started. The existing synchronous `RenderEngine` entrypoints now delegate their GL bodies to named `...OnRenderThread(...)` helpers, but no command queue or dedicated render thread exists yet.
- Phase 4 implementation: Step 2 started. The existing synchronous `RenderEngine` entrypoints delegate their GL bodies to named `...OnRenderThread(...)` helpers, and preview/screenshot/render-reset requests now pass through a small `RenderCommandQueue` compatibility mailbox. No dedicated render thread exists yet.
- Current alignment: the repo has a named frame-state contract and cleaner render-state preparation, but GL work is still entered through multiple paths protected by one shared `CRITICAL_SECTION`.
Current GL ownership footholds:
- `RenderEngine` owns GL resources, the current context-binding compatibility shims, and named render-thread helper methods.
- `RenderEngine` owns GL resources, the current context-binding compatibility shims, a small render command mailbox, and named render-thread helper methods.
- `RenderFrameInput` / `RenderFrameState` provide the frame-state contract that a render thread can consume.
- `RenderFrameStateResolver` prepares the render-facing layer state before drawing.
- `OpenGLVideoIOBridge` still calls `RenderEngine::TryUploadInputFrame(...)` from the input path and `RenderEngine::RenderOutputFrame(...)` from the output path.
@@ -129,6 +129,13 @@ Non-responsibilities:
Small bounded queue or command mailbox for render-thread work.
Current implementation:
- `RenderCommandQueue` exists as a pure C++ mailbox helper.
- Preview present and screenshot capture requests use latest-value coalescing.
- Render-local reset requests coalesce to the strongest pending reset scope.
- `RenderEngine` drains these commands synchronously as compatibility shims until a dedicated render thread is introduced.
Possible commands:
- `UploadInputFrame`
@@ -224,9 +231,9 @@ Introduce a small queue/mailbox for render commands.
Start with low-risk commands:
- preview present request
- screenshot request
- render-local reset requests
- [x] preview present request
- [x] screenshot request
- [x] render-local reset requests
Then move input upload and output render requests once the queue and wakeup behavior are proven.