OCIO and Fullscreen stubs
All checks were successful
CI / React UI Build (push) Successful in 12s
CI / Native Windows Build And Tests (push) Successful in 2m10s
CI / Windows Release Package (push) Has been skipped

This commit is contained in:
2026-06-03 01:08:43 -04:00
parent 8a6bb81a37
commit 659fbef1a5
11 changed files with 472 additions and 0 deletions

View File

@@ -248,6 +248,34 @@ http://127.0.0.1:<serverPort>
`/api/state` exposes backend-neutral output telemetry in `videoOutput`. Use `videoOutput.enabled`, `videoOutput.backend`, and `videoOutput.scheduleFailures` for portable status. Backend-specific counters live in `videoOutput.backendMetrics`.
### Borderless Window / Fullscreen Output Plan
The preview window is a best-effort diagnostic view and is allowed to drop or reuse frames without disturbing cadence. A borderless window or fullscreen display output should be implemented as a real `output.backend`, separate from preview, so it can target full configured resolution and frame rate.
Rough plan:
- Add a `window` video output backend behind the existing `IVideoOutput` factory, selectable with `"output": { "backend": "window", ... }`.
- Give it its own device/display selection, fullscreen/borderless mode, window position, vsync policy, and optional monitor refresh validation in `runtime-host.json`.
- Consume `SystemFrameExchange` frames like the other output backends, on an output-owned thread, without blocking the render thread.
- Upload/present frames through a dedicated GL/DX window context or shared-context path, with a bounded mailbox so late window presentation never back-pressures render cadence.
- Report backend-neutral telemetry through `videoOutput` and put display/window-specific details under `videoOutput.backendMetrics`.
- Keep the existing preview window as an operator confidence monitor only, not as the full-quality display output path.
### OCIO / Linear 16-Bit Float Pipeline Plan
The render backend should move toward a true linear-light `RGBA16F` pipeline, with OpenColorIO used for explicit color transforms at the video I/O and display edges. Shader packages should be able to assume a stable working space instead of guessing whether input pixels are display-referred, log, Rec.709, HDR, or already linear.
Rough plan:
- Add OCIO as an optional third-party dependency and package its required runtime DLLs, config files, and license notices with Release builds.
- Extend `runtime-host.json` with color settings for input, working, output, and preview/display transforms, including OCIO config path, input color space, working color space, output color space, view, look, exposure, and gamma.
- Convert captured/input frames into the configured linear working space before shader layers sample them.
- Allocate runtime render targets, temporal history, feedback buffers, and intermediate layer buffers as `RGBA16F` by default, with explicit fallbacks for unsupported hardware.
- Keep shader parameter uploads and texture assets explicit about color intent: data textures stay data, image/video textures can opt into OCIO or known transfer conversion.
- Apply the output transform only at backend edges: DeckLink/NDI/window output, screenshots, and preview each get the correct display/output transform for their target.
- Prebuild OCIO GPU shader/lut resources off the render thread and commit prepared resources to the render thread only when ready, following the render cadence golden rules.
- Add test coverage for config parsing, color-pipeline defaults, fallback behavior, and shader/runtime state reporting.
## Runtime State
The current layer stack is autosaved to `runtime/runtime_state.json` whenever durable UI/API layer changes are accepted: add/remove, shader assignment, bypass state, ordering, parameter updates, parameter reset, and reload compatibility refreshes. Saves are debounced and written on a background worker, with a final flush during shutdown.