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

Step 5 storng option
Some checks failed
CI / React UI Build (push) Successful in 10s
Details
CI / Native Windows Build And Tests (push) Successful in 2m41s
Details
CI / Windows Release Package (push) Has been cancelled
Details

Browse Source
This commit is contained in:
Aiden
2026-05-11 19:20:23 +10:00
parent ff10b66d1d
commit 79855d788c
10 changed files with 247 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/subsystems/RenderEngine.md
View File

@@ -113,7 +113,7 @@ Phase 5's `RuntimeStateLayerModel` explicitly keeps temporal history, feedback s
`RuntimeLiveState` now owns transient automation invalidation for render-facing compatibility. It can clear overlays for a target layer/control key and prunes overlays that no longer resolve to the current layer and parameter definitions before applying them to a frame. This keeps shader reload, preset load, and layer removal behavior local to the live-state/composition boundary instead of scattering it through GL drawing code.
Render snapshots now flow through a named `CommittedLiveStateReadModel`, so render-facing committed state is distinct from durable storage even while both are physically backed by the same store during migration.
Render snapshots now flow through a named `CommittedLiveStateReadModel`, so render-facing committed state is distinct from durable storage and physically owned by `CommittedLiveState`.
### 5. Shader Build Application

2
docs/subsystems/RuntimeCoordinator.md
View File

@@ -274,7 +274,7 @@ For OSC specifically, the coordinator should eventually decide:
Phase 5 sets the default settled OSC policy to session-only. `CommitOscParameterByControlKey(...)` updates committed session state through the store with persistence disabled, publishes ordinary mutation/state-change observations, and does not request a persistence write unless a future explicit policy opts into durable OSC commits.
The committed-live concept now has a named read model, `CommittedLiveStateReadModel`. The coordinator remains the owner of whether a mutation should be durable or session-only, while `RuntimeStore` temporarily backs the read model until a physical `CommittedLiveState` collaborator is worth extracting.
The committed-live concept now has a physical owner, `CommittedLiveState`, plus a named read model, `CommittedLiveStateReadModel`. The coordinator remains the owner of whether a mutation should be durable or session-only, while `RuntimeStore` persists or skips disk writes according to that policy.
### Health and timing state

2
docs/subsystems/RuntimeStore.md
View File

@@ -97,7 +97,7 @@ Those are coordinator concerns, not store concerns.
Phase 5 names this boundary in code through `RuntimeStateLayerModel`: persisted layer stack data, saved parameter values, and stack presets are classified as base persisted state. Operator/session values may still be backed by the store during migration, but their mutation policy is committed-live policy owned by the coordinator, not durable-store policy by default.
Phase 5 also adds `CommittedLiveStateReadModel` as the named read boundary for current session/operator state. During the conservative migration, `RuntimeStore` still backs that model physically, but snapshot publication consumes the committed-live read model rather than treating render-facing state as raw durable storage.
Phase 5 also adds `CommittedLiveState` as the physical owner of current session/operator layer state and `CommittedLiveStateReadModel` as the named read boundary for render snapshot publication. `RuntimeStore` still owns file IO, config, package metadata, preset persistence, and persistence requests, but it delegates current-session layer mutations to `CommittedLiveState`.
### Runtime Configuration