Part 6 of the Metal PathTracer Architecture series, based on the renderer documentation snapshot created on May 14, 2026.

One of the easiest assumptions to make about a real-time renderer is that recording the screen is passive. The renderer produces a frame, the operating system copies or encodes it, and the result is a video of the same experience. That assumption held until the workload became heavy enough to leave almost no spare frame-time.

In my current Metal path-tracing experiments, macOS native screen recording has added enough overhead on heavier scenes to change the observed frame pacing. OBS has behaved better in the tests so far, although I have not isolated the exact reason. The result is a practical and methodological lesson: capture is part of the workload when the renderer is close to its interactive budget.

A frame has more consumers than the integrator

The obvious work in a path-traced frame is the renderer itself: ray queries, shading, sampling, denoising, and presentation. A capture path competes with that work for several of the same finite resources.

It can add GPU compute pressure, compositor work, texture readback or encode paths, memory bandwidth, and thermal or scheduling headroom. None of those activities needs to be individually dramatic. When the renderer has a comfortable margin, a little extra work may be invisible. When a heavy scene is already near the frame-time limit, the same overhead can become an obvious change in pacing.

This is why a recorded video can be less representative than a live session even when the camera, scene, and renderer settings are identical. The act of observing the frame has changed the conditions under which the frame is produced. The capture is not simply a window onto the workload; it is another participant in it.

What the current observation does—and does not—say

The observation is intentionally narrow. On the heavier scenes tested so far, macOS native recording appears to add enough overhead to degrade the result compared with the live interactive experience. OBS has behaved better in those tests. I have not established a universal explanation, and I am not treating the observation as a claim that macOS screen recording is generally broken.

The videos should therefore be read as qualitative captures of the current renderer state, not benchmarks. They show what the interaction looks like under a particular capture setup. They do not establish a frame rate, a reproducible performance ranking, or a hardware-independent measurement. That distinction matters especially for a renderer with several gated paths and reconstruction experiments, where small changes in workload can affect the visible result.

Calling the videos qualitative is not a dismissal of their value. Interactive captures are useful for showing motion, lighting response, camera exploration, and the character of an experimental feature. They can make an architectural idea tangible in a way a table of timings cannot. The important part is to describe what they are evidence of and avoid asking them to answer a question they were not designed to answer.

Designing a more useful capture

The next step is to make the capture conditions part of the record. For each representative video or measurement, I want to note the Mac model and SoC, macOS version, display resolution and refresh rate, internal render resolution, samples per frame, path depth, active feature gates, capture method, and whether the capture is fullscreen, windowed, or on an external display.

Those details provide context for both the image and the pacing. Internal render resolution and samples per frame describe the renderer's work. Display and capture mode describe the presentation path. Feature gates identify whether a cache, reuse pass, or denoiser is contributing. Without that context, “the renderer runs smoothly” is too vague to reproduce and “recording costs ten percent” is too precise to trust.

GPU timing buckets would make the comparison more useful still. Separating integration, presentation, and denoising can show where the renderer spends its time. Instruments or a Metal System Trace may help distinguish that work from compositor and encode activity. The goal is not to collect impressive-looking numbers; it is to find a controlled way to observe a near-budget renderer without substantially changing its behavior.

That is a difficult measurement problem. A profiler or recorder also needs resources, and the very act of adding instrumentation can perturb scheduling and bandwidth. The right answer may involve more than one capture mode: a lightweight qualitative recording for communication, a controlled GPU capture for a single frame, and a trace-based run for timing evidence. Each answers a different question.

Choosing what to publish

For public work, I prefer to be explicit about this limitation. A video can communicate the current state of an interactive experiment, but it should not be presented as benchmark evidence unless the capture conditions have been controlled and documented. On heavier scenes, I will use the method that better preserves the live behavior and say what that method was.

This also changes how I interpret my own debugging sessions. If a scene feels worse only while recording, that does not immediately identify a renderer regression. It may be the capture path consuming the frame-time margin. Conversely, if a capture looks smooth, that does not prove the renderer has spare capacity; the recording setup may simply be less disruptive.

The practical question I am carrying forward is: how can a near-frame-budget Metal compute renderer be captured or profiled without substantially distorting frame pacing? Answering it will require a focused trace or reproducible case, including the machine, operating-system, display, renderer, and capture details. Until then, the honest boundary is straightforward.

The recordings are windows into an experiment, not laboratory benchmarks. When screen recording becomes part of the workload, that sentence is not a disclaimer added after the fact. It is part of the technical description of the result.

Series navigation

Previous: History Is a Rendering Resource.

Start the series: Building a Metal Path Tracer into an Interactive Research Renderer.