Performance

Numbers we can prove.

Benchmark claims are marketing until you can reproduce them. Here's exactly how we measure, on what hardware, and the commands to run the same benchmark on your own Mac.

< 1%

avg CPU @ 4K60

< 50 MB

RAM (RSS), capture engine

dropped frames

Methodology

Hardware: Apple Silicon (aarch64), macOS 26.5. Benchmark date: July 2026. Runs are 8–20 seconds — long enough for the pipeline to reach steady state, which is what the averages describe.

What the RAM figure covers: the capture engine, measured at 19 MB RSS. The app's window adds roughly 100 MB on top; CPU is unaffected.

Workload: screen content is kept churning during the whole run — a terminal redrawing at 250 Hz — so ScreenCaptureKit ships a full frame stream. Static-screen numbers would flatter everyone.

Measurement: mach_task_basic_info — the same source Activity Monitor reads. Every number here is measured by the built-in benchmark harness on the hardware above; your own results will vary with machine and workload, which is why the reproduce-it-yourself commands are right here.

reproduce it yourself

# churn the screen (terminal rapid redraw):
( for i in $(seq 1 6000); do \
    printf "\r%s  " "$(date +%N)"; sleep 0.004; \
  done ) &

# measure at 1080p60 and 4K60:
wispframe probe --display 1 --duration 10 --fps 60 \
  --width 1920 --height 1080 --bench mine
wispframe probe --display 1 --duration 10 --fps 60 \
  --width 3840 --height 2160 --bench mine-4k

Results

App	Avg CPU	Peak CPU	RAM (RSS)	Dropped frames
Wispframe (1080p60)	< 1%	< 1%	< 50 MB	0
Wispframe (4K60)	< 1%	< 1%	< 50 MB	0

CPU under sustained load

Sustained load is where recorders fall apart — thermal pressure, fan noise, dropped frames. A hardware-only pipeline doesn't accumulate any of it.

Illustrative. Our line is the measured average from the runs above, held constant; the comparison band reflects publicly reported ranges for CPU-copy recorders and is not our own measurement. Our published runs are 8–20 seconds — the length it takes for the pipeline to reach steady state.

Why it's this fast

Zero-copy IOSurface pipeline

ScreenCaptureKit delivers frames directly from the GPU to VideoToolbox hardware encoding. Pixels never touch the CPU — no memcpy, no format conversion, anywhere in the hot path.

Hardware-only encoding

VTCompressionSession runs on the media engine, not CPU cores. The CPU's only job is shuffling buffer handles around.

Rust, without a runtime

No garbage collector, no JIT warmup, no scheduler jitter. The encoder thread is a tight lock-free loop fed by a bounded ring buffer.

Dirty-rectangle delivery

ScreenCaptureKit only ships frames when pixels change. A static screen produces near-zero work — CPU sits at ~0%.

Every feature ships inside a performance budget: <0.5% CPU and <20 MB RAM overhead, verified with the same benchmark harness before merge.