vello_cpu
github.com/linebender/vello · Apache-2.0 OR MIT
For hotty-blitz
2 patches on 0.1.0. Blitz paints through anyrender, and hotty-blitz renders surfaces on the CPU with anyrender's vello_cpu backend, which brings vello_cpu 0.1.0 from crates.io: the published package, not the vello repository, because its dependencies are the crates.io ones anyrender builds against. A terminal repaints small parts of its surfaces many times a second, which is where these two patches save. We mod vello_cpu rather than fork it so that they stay two changes on the version we build with. Both still apply to vello_cpu 0.3.0.
The patches, each with its upstream fit:
- Flushing waits for the workers without spinning — yes
- A render context takes at most 4 workers by default — maybe
Flushing waits for the workers without spinning
Upstream fit: yes · patch 0001
What it changes: MultiThreadedDispatcher::flush drained the workers'
recorded commands by looping on try_recv until every worker had hung up,
so the painting thread spun at full speed for as long as the workers took
on the last batch. It now blocks in the ordered channel's recv, which
hands out the tasks in the same order and fails once the senders are gone
and nothing is buffered. Counting instructions with perf on a 10 Hz
dashboard in hottyterm: the painting thread did 39% fewer, the process 23%
fewer, and frame times stayed the same.
Why we carry it: a quarter of hotty-blitz's instructions on that dashboard were this spin.
For upstream: yes. It is a fix with no trade-off: the order and the results are the same, and only the busy wait goes. vello_cpu 0.3.0 still drains this way, and the patch applies there.
A render context takes at most 4 workers by default
Upstream fit: maybe · patch 0002
What it changes: the default thread count was one worker per core but one, up to 8; it is now up to 4. Measured with a 300-frame dashboard replay and hotty-blitz's benchmark on a Ryzen 5 5600X and a laptop: past 2 workers a full paint barely gets faster, since the main thread's share dominates, while each worker adds dispatch and idle spinning to every small paint. With 4, replay paint time fell about 16% and CPU time about 35% on the 5600X, and a full paint stayed within a millisecond.
Why we carry it: HOTTY repaints are mostly small, and a host keeps 8 render contexts, so this halves its threads, from 64 to 32. The maintainer chose 4 (2026-10-10).
For upstream: maybe. The measurement is worth having: on two machines,
past 2 workers a full paint barely gets faster, and every worker costs
each small paint. But the right default depends on what a renderer
paints, upstream's benchmarks may differ, and a caller can already set
num_threads. vello_cpu 0.3.0 still takes up to 8.