Phase 7.5 timing logs
Some checks failed
CI / React UI Build (push) Successful in 11s
CI / Native Windows Build And Tests (push) Successful in 2m45s
CI / Windows Release Package (push) Has been cancelled

This commit is contained in:
Aiden
2026-05-11 21:32:40 +10:00
parent 0a7954e879
commit f8adbbe0fe
8 changed files with 457 additions and 4 deletions

View File

@@ -11,7 +11,8 @@ Phase checklist:
- [x] Make the render thread the sole GL owner
- [x] Refactor live state layering into an explicit composition model
- [x] Move persistence onto a background snapshot writer
- [ ] Make DeckLink/backend lifecycle explicit with a state machine
- [x] Make DeckLink/backend lifecycle explicit with a state machine
- [ ] Make playout timing proactive and deadline-aware
- [ ] Add structured health, telemetry, and operational reporting
Checklist note:
@@ -632,6 +633,21 @@ Expected benefits:
- easier handling of missing input, dropped frames, or reconfiguration
- a clearer place to own playout headroom policy, output queue sizing, and late-frame recovery behavior
### Phase 7.5. Make playout timing proactive and deadline-aware
Phase 7 made backend lifecycle, ready-frame queueing, measured recovery, and backend playout health visible. The remaining timing-specific work is to make output production proactive instead of demand-filled by completion pressure.
Dedicated design note:
- [PHASE_7_5_PROACTIVE_PLAYOUT_TIMING_DESIGN.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/PHASE_7_5_PROACTIVE_PLAYOUT_TIMING_DESIGN.md)
Expected benefits:
- output frames are produced ahead based on queue pressure or cadence
- DeckLink completion handling normally consumes already-ready frames
- preview and synchronous readback fallback become explicitly subordinate to playout deadlines
- queue depth, readback misses, preview skips, and render timing explain why headroom drains
### Phase 8. Add structured health, telemetry, and operational reporting
This phase should happen after the main ownership changes so the telemetry can reflect the final architecture instead of a transient one.
@@ -680,7 +696,8 @@ If this is approached as a serious architecture program rather than opportunisti
5. Formalize live state layering and composition.
6. Move persistence to a background snapshot writer.
7. Refactor DeckLink/backend lifecycle into an explicit state machine.
8. Add structured telemetry, health reporting, and operational diagnostics.
8. Make playout timing proactive and deadline-aware.
9. Add structured telemetry, health reporting, and operational diagnostics.
## Why This Order Makes Sense
@@ -703,6 +720,7 @@ The app is in a much better place than it was before the OSC timing work. The sh
5. formalize layered live state
6. complete background persistence
7. explicit backend lifecycle
8. health and telemetry
8. proactive playout timing
9. health and telemetry
That sequence gives each later phase a cleaner foundation than the current app has today.