prec, measured

One run of prec's docs/bench/bench.sh on 2026-10-16: an AMD Ryzen 9 9950X on Linux, prec 1.2.0 and VHS v0.11.0 pinned to the same 24 threads, recording the sample app's 10-second tour.tape at 1280x720.

Against VHS

Every frame at the rate you ask for, then the re-render times and the one binary.

Paired bars, frames in a 10-second clip at 1280x720, higher is better. Asked for 30 fps: prec 299, VHS 239, 1.3× more frames. 60 fps: 598 and 228, 2.6×. 120 fps: 1196 and 214, 5.6×.
Frames in the clip prec steps a virtual clock at exactly 1/fps and draws every frame; VHS captured in real time. VHS wrote a 25 fps file of 9.6, 9.1 and 8.6 seconds.
Paired bars, frames per second of the file written for one 10-second tape at 1280x720, higher is better. Asked for 30 fps: prec 30, VHS 25. 60 fps: 60 and 25. 120 fps: 120 and 25.
Frame rate of the file written Ask for 30, 60 or 120 fps and the file is 30, 60 or 120 fps, 9.97 s long; VHS wrote 25 fps at every setting.
Bars, seconds to replay and encode a 10-second cast with prec 1.2.0, lower is better: 720p 30 fps 9.2 s, 1080p 60 fps 16.9 s, 2160p 30 fps 27.8 s, 2160p 120 fps 48.6 s.
Re-render from the cast No app run: the cast replays in headless Chromium and is encoded at CRF 14. Two 720p renders of one cast wrote the same master, sha256 4fab0be36a0ac519…
Bars, megabytes for Linux x86_64, prec 1.2.0: the binary 5.7 MB, the release .tar.gz 2.4 MB.
One binary, nothing to download Fat LTO, one codegen unit, stripped. xterm.js, the VHS themes and pito-codecs' H.264 encoder are compiled in, so prec runs no encoder of yours and reads nothing from the network.

Every row of the run

Both tools on the same tape at each rate, then the cast re-rendered from 720p to 4K.

Asked for prec frames prec clip prec wall time VHS frames VHS file VHS wall time
30 fps 29930 fps, 9.97 s20.5 s23925 fps, 9.56 s13.9 s
60 fps 59860 fps, 9.97 s21.7 s22825 fps, 9.12 s14.3 s
120 fps 1,196120 fps, 9.97 s23.4 s21425 fps, 8.56 s15.2 s

VHS finishes sooner, because it keeps what it can capture in real time; prec records in real time, then replays and encodes every frame at CRF 14 with pito-codecs' H.264 encoder. A frame's moment that brings no new bytes reuses the previous frame, so a mostly still terminal replays faster than a busy one.

Re-rendering the cast

Size and rate Frames Time
720p, 30 fps 2999.2 s
1080p, 60 fps 59816.9 s
2160p, 30 fps 29927.8 s
2160p, 120 fps 1,19648.6 s

The 30 fps recording's cast, with no app run. The 720p render again took 9.8 s and wrote the same bytes.

How it was measured

docs/bench/bench.sh, once, on 2026-10-16: both tools pinned to the same 24 threads (CPUS=4-15,20-31) at nice 10, prec 1.2.0 with PREC_DIRECT=1 and VHS v0.11.0, recording the sample app's tour.tape (about 10 seconds of typing, progress bars and the palette) at 1280x720. The Linux x86_64 binary is 5,935,688 bytes, 2,508,494 packed as the release's .tar.gz; a cold cargo build --release --locked took 70.4 s with 4 build jobs; src/ is 10,912 lines of Rust with 18 direct dependencies. Renders on a Mac are untested.

Every number is from prec's README at v1.4.6.

Read it. Run it. It's MIT.

Download prec 1.5.1 Linux and macOS Get it on GitHub github.com/gmrdad82/prec Read the docs docs.pitomd.com/prec

The code is MIT licensed, © Catalin Ilinca: read it, fork it, ship it in your own work. Its name and logos, and PITO MD's, are © Catalin Ilinca, all rights reserved, and are not covered by the MIT licence.

Credits

The charts are drawn by pito-compare from prec's docs/bench data and from numbers its README states.

prec vendors xterm.js 5.5.0 and VHS v0.11.0's 348 colour schemes, both under the MIT licence; their notices are in its NOTICE.

Set in Archivo by Omnibus-Type and Atkinson Hyperlegible Mono by the Braille Institute, both under the SIL Open Font License.