docs: HANDOFF — de-duplicate the sliced-6/7 history paragraph

This commit is contained in:
2026-09-04 12:37:26 -07:00
parent fbc8562cf4
commit c46f3a1168
+8 -8
View File
@@ -52,14 +52,14 @@ RealApp boot-smoke. Scope-check passed.
not cache keys. Tests: `PasteCache_...` + 85/85 across compositor/pump/chat/capture/session not cache keys. Tests: `PasteCache_...` + 85/85 across compositor/pump/chat/capture/session
classes; clean build 0 warnings. (Cam bypasses the cache via IsOpaque; revisit if take 9 is classes; clean build 0 warnings. (Cam bypasses the cache via IsOpaque; revisit if take 9 is
borderline. Follow-ups unchanged: vertical-tier alloc, debounced chat re-render on bursts.) borderline. Follow-ups unchanged: vertical-tier alloc, debounced chat re-render on bursts.)
3. **Take 9/10 + slices 6-7 (2026-09-04):** slice 6 broke the 15.6ms Task.Delay sleep quantum (timeBeginPeriod + bulk-sleep + 2ms spin tail + wait stat); take 10's `wait 10ms after render 22ms` then exposed the FINAL structural bug: the pump loop's await-continuations inherited the UI SynchronizationContext — the "WPF-free" producer had been rendering ON THE DISPATCHER, queued behind the live preview, the whole time (explains every 'zero change' complaint). Slice 7: Task.Run the loop (OBS pattern) + StaticPixelCache lock + chat raster-miss marshalled to dispatcher + SustainedLowLatency GC + `worst render` stat + webcam through paste cache. Test `Pump_Produces_OffTheStartingContext`. 70/70 green, clean build. paste cache moved render 26.5→22.4ms yet 3. **Slices 6-7 (2026-09-04, committed):** slice 6 broke the 15.6ms Task.Delay sleep quantum
period stayed ~37ms — the gap is Task.Delay's ~15.6ms Windows sleep quantum padding every sub-tick (timeBeginPeriod + bulk-sleep + 2ms spin tail + `avg wait` stat — the quantum had capped the
wait. **This is why takes 7→9 read as "zero change" despite real wins: the sleep floor dominated.** producer at ~27fps and made two real render wins read as "zero change"). Slice 7 then resolved
Fixed (media-app canon, cited in code + MyMistakes #3): timeBeginPeriod(1) for the pump's life take 10's impossible math (`render 22 + wait 10` vs a 16.7 deadline): the pump's continuations
(paired End in finally), sleep the bulk, SPIN the last 2ms across the deadline; stats gained inherited the UI SynchronizationContext — the loop had been rendering on the dispatcher behind
`avg wait` so render+submit+wait ≈ period (accounting closed — nothing can hide). Webcam now the live preview the whole saga. Task.Run the loop (OBS pattern), StaticPixelCache locked, chat
routes through the paste cache too (bypass re-sampled 156k px even between identical device raster-miss marshalled to the dispatcher, SustainedLowLatency GC, `worst render` stat, webcam
frames). 52/52 per-class green, clean build 0 warnings, committed this slice. through the paste cache. Tests Pump_Paces/Pump_Produces_OffTheStartingContext; 70/70 green.
4. **Take 11 ran + slice 8 (2026-09-04, committed with the audio unit below):** off-UI loop 4. **Take 11 ran + slice 8 (2026-09-04, committed with the audio unit below):** off-UI loop
WORKED — typical frames land exactly on the deadline (work ~10 + wait ~6.8 = 16.7; 212/300). WORKED — typical frames land exactly on the deadline (work ~10 + wait ~6.8 = 16.7; 212/300).
Remaining gap = periodic 35-65ms spikes growing across the take = gen2 GC pauses; the capture Remaining gap = periodic 35-65ms spikes growing across the take = gen2 GC pauses; the capture