@@ -23,7 +23,7 @@ Before the Phase 1 runtime split, the closest behavior lived in:
-`RuntimeHost::BuildLayerRenderStatesLocked(...)`
- the render-side cache usage in [OpenGLComposite.cpp](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/apps/LoopThroughWithOpenGLCompositing/gl/composite/OpenGLComposite.cpp:589)
`RuntimeSnapshotProvider`should absorb that responsibility, but in a cleaner and more publish-oriented way.
`RuntimeSnapshotProvider`has absorbed that responsibility in a cleaner and more publish-oriented way.
## Responsibilities
@@ -220,9 +220,9 @@ The target read contract for `RenderEngine` should be:
Important rule:
-`RenderEngine` should never partially mutate the provider’s published snapshot in place
-`RenderEngine` should never partially mutate the provider's published snapshot in place.
That means today’s`TryRefreshCachedLayerStates(...)`behavior is a migration waypoint, not a target pattern. Once the provider exists, the render side should treat the snapshot as immutable input and keep any overlays or last-frame adjusted values inside `RenderEngine`.
The old`TryRefreshCachedLayerStates(...)`host path is gone. The remaining dynamic refresh is explicit: `RuntimeSnapshotProvider::RefreshDynamicRenderStateFields(...)` updates frame-local fields on render-owned copies, while published snapshot structure and committed parameter data stay behind the provider boundary.
## Render-Facing Data Shape Rules
@@ -338,42 +338,7 @@ This is especially important while migrating away from the current lock/fallback
## Current Code Mapping
The current code follows this migration map.
### Move into `RenderSnapshotBuilder`
From `RuntimeHost`:
- layer render-state construction from `BuildLayerRenderStatesLocked(...)`
- render-facing translation of layer persistent state plus package metadata
- explicit version composition for render-visible state
- dynamic frame-context construction currently done in `RefreshDynamicRenderStateFields(...)`
### Move into `RuntimeSnapshotProvider`
- published snapshot cache ownership
- version matching for already-published snapshots
- render-facing compatibility API while render callers migrate
### Stop exposing directly from the host/store boundary
Current methods that should become compatibility shims and later disappear:
-`GetLayerRenderStates(...)`
-`TryGetLayerRenderStates(...)`
-`TryRefreshCachedLayerStates(...)`
-`RefreshDynamicRenderStateFields(...)`
### Render-side compatibility during migration
The previous `OpenGLComposite` cache path:
- read versions from `RuntimeHost`/store-owned counters
2. compare snapshot versions produced by `RenderSnapshotBuilder`
@@ -381,7 +346,20 @@ The migrated runtime path is:
4. apply render-local overlay state
5. attach frame context
That is a much cleaner split than the current mixed lock/cache/fallback flow in [OpenGLComposite.cpp](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/apps/LoopThroughWithOpenGLCompositing/gl/composite/OpenGLComposite.cpp:589).
That replaced the old mixed lock/cache/fallback flow that lived around [OpenGLComposite.cpp](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/apps/LoopThroughWithOpenGLCompositing/gl/composite/OpenGLComposite.cpp:589).
`RenderSnapshotBuilder` now owns:
- layer render-state construction
- render-facing translation of committed live state plus package metadata
- explicit version composition for render-visible state
- dynamic frame-field refresh for render-owned copies
`RuntimeSnapshotProvider` now owns:
- published snapshot cache ownership
- version matching for already-published snapshots
- publication events and snapshot publish observations
## Migration Plan
@@ -403,8 +381,8 @@ That is a much cleaner split than the current mixed lock/cache/fallback flow in
### Step 4: Remove mutable snapshot refresh paths
-retire`TryRefreshCachedLayerStates(...)`
- publish new snapshots for committed parameter changes instead of mutating render-cached host-derived vectors in place
-completed: retire the old`TryRefreshCachedLayerStates(...)` host path
- publish new snapshots for committed parameter changes instead of mutating published snapshot structure in place
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.