5. Inspect ready inputs and wait for the next useful tick
Avoid scanning every source on every arrival. Bound housekeeping without changing the output tick or treating late output as a success.
Reviewed 15 October 2026 against e72ff8b4. These pages describe that code and named workload settings; they do not assert what every deployment runs.
Readiness, then bounded polling
Multi-event waits report which inputs signalled, so the compositor drains those inputs instead of peeking every queue on every wake. Linux epoll avoids rebuilding a large descriptor scan. Optional canvas.input_poll_ms and canvas.aux_input_poll_ms batch input housekeeping between tick deadlines; the L4 profile sets both to 8 ms.
The generic parser leaves these options unset. Eight milliseconds is a workload setting, not the frame deadline and not a universal optimum. Scene commands must still wake the relevant path promptly. Keep the input queues large enough for arrivals between checks.
Bound frames that can still be displayed
Compositor playout releases superseded frames even when it is not ready to draw the next tick. Decoder lookahead can be bounded upstream so hidden queue depth does not pin extra decode surfaces. These bounds control retained work; they cannot make an expensive transition fit into a tick.
At 50 fps output ticks are 20 ms apart. Playout latency, input polling, GPU draw duration and output cadence are different quantities. A single late tick can recover; sustained work above available throughput cannot. Downstream frame-rate normalization may repeat output even when compositor miss counters remain zero.
Measured CPU savings, with their original scope
On the historical 192-source 30 fps show, epoll reduced the busiest compositor from 51.8 to 34.7% of one core. Later signalled-input and polling changes reduced each Program compositor from 12.1 to 7.3%. These are sequential historical readings, not additive independent savings. Original wait measurements · later input/polling sequence.
Acceptance
Exercise cuts and fades into the heaviest supported scenes. Inspect actual on-air delivery after output pacing as well as draw times, queue depths and CPU. Preserve a GPU/output budget; do not increase polling intervals simply to make CPU usage look smaller.