mixer_keyer: compose only the rectangles of keys that say so

[jpietek]

What

With keys visible the keyer composes the whole canvas in one launch: the program as a full-size layer under the keys. A key on a small part of the picture pays for all of it.

Keys named in bounded_keys (a dsk key's bounded option in a show) may be composed alone. While every visible key is one of them, the output is a copy of the program frame on which the composite kernel runs only over viewports around the keys. Keys that overlap share a viewport.

• The composite kernel is unchanged. A viewport is handed to it as its canvas: plane pointers at the viewport's origin, the viewport's size, and a rect table relative to that origin (cuda_rect_viewport.h).
• At most four rectangles and 60 % of the canvas; beyond that, and for any other layer set, the whole canvas is composed as before.
• Whole-canvas composition stays the default. bounded_keys is an array of key inputs, or true for all.
• The mixer demo marks its four keys: each window is its graphic and nothing else.

Measured

Tesla T4, 1920x1080 NV12, one blended RGBA key, kernel time per frame from tests/cuda/test_rect_composite.cu:

Key	Whole canvas	Copy + viewport
1016x172	0.161 ms	0.091 ms
1920x360	0.252 ms	0.207 ms
1920x1080	0.502 ms	whole-canvas path

The program frame is shared with the clean output, so it is copied first; that copy costs most of what the bounded launch saves.

Tests

• tests/cuda/test_rect_composite.cu: fifteen over: cases (NV12, P010, P210; premultiplied, texture-backed, faded, scaled, overlapping, off-canvas keys) whose pixels must equal the whole-canvas launch. A deliberately wrong chroma origin fails it.
• tests/mixer/test_graph.py: the show option reaches the node; a non-boolean is refused.
• Ran in a 192-source show with all four keys bounded.

🤖 Generated with Claude Code