Historical evidence and superseded recipes
Original measurements remain useful when their workload and revision stay attached.
Reviewed 15 October 2026 against e72ff8b4. These pages describe that code and named workload settings; they do not assert what every deployment runs.
These pages retain original diagrams, source revisions and workload evidence. Their deployment labels, defaults and recommendations have not been requalified. Use the current performance recipes for the reviewed implementation.
Previous versions of rewritten recipes
- Browser frames go back one per new frame
- Colour tags at the fan-out
- The compositor's wait costs the frames that arrived
- One main CUDA stream, one per monitor
- DSK fades in one pass
- Event-loop sharding
- Input, decode and wake-ups: 502 to 234 % of a core
- NVDEC arrays without a staging copy
- Raw frames read straight into the memory the GPU reads
- Source limits by mode and frame rate
Earlier experiments and focused recipes
- Browser frame ticks staggered at 60 fps
- Browser frame hand-off
- Browser CPU is per painted frame
- Chromium paints into the buffer the mixer reads
- Unused GPU contexts
- cuda_transform, the shared geometry node
- One thread per GPU filter graph
- Native input cadence without force_fps
- GPU memory: frames no tick can show any more
- Keeping Vulkan out of the GPU process
- Prewarmed DSK keys
- Looped clips keep counting across the wrap
- Multiviewer: 192 sources, 12 at a time
- One reference frame for monitor encoders
- PGM delay instead of a longer aux deadline
- Real 1080p inputs, no shortcuts
- Ideas we measured and dropped
- A wipe clip is cached whole or the start fails