[ccoventry]

Release note: New: "Render while capturing" can run up to 4 renders at once beside the capture (Renders at once), so renders keep up with a long batch.

Why

Measured on a 213-clip WSOD25 batch (Ryzen 7 9800X3D, 16 threads, ProRes 422 at 300 fps): with one render beside the capture, the CPU averaged ~33 % busy. Capture recorded ~15 clips an hour, but only ~2.8 clips an hour were rendered, so takes piled up and the renders set the pace (10 rendered in 3.6 h). After the capture stopped, 4 renders at once ran the CPU at 100 %, each FFmpeg using about as much CPU as the lone one had beside the capture.

What changes

• Configuration's "Render while capturing" line gets Renders at once (1–4, default 1, dimmed while the setting is off). Each choice shows the CPU share it takes, e.g. "2 (about 50% of the CPU)": the choice over the Render tab's own number, updated when that number changes. It's saved as renders_while_capturing; settings saved before it read as 1.
• render_manager.rs: concurrency_cap takes the setting while a capture runs instead of the fixed RENDERS_WHILE_CAPTURING = 1, never more than the Render tab's own number. Each render still gets the threads one of the Render tab's renders would (thread_share), so 2 at once takes about half the CPU at the default 4.
• capture_room_manager.rs reads the setting when the batch starts, and the activity log's start line says how many renders ran ("up to 2 renders at a time").
• A held batch (nothing recording) still runs the Render tab's full number, as before.

HLAE records frame by frame, so a busier CPU slows the capture but drops no frames.

Test done

• cargo test -p desktop-studio (283 passed), including the new cap cases (setting within the Render tab's number, never 0) and the log line's wording.
• rendersAtOnceFrom, cpuSharePercent and label unit tests; npm run test:unit (1,434 passed); eslint no errors; clippy and rustfmt with 1.98.1.
• Not run in a real batch yet: the user's next overnight batch at 2 is the test (watch the CPU and the clips rendered per hour).

🤖 Generated with Claude Code

[ccoventry]

Raised settings_manager.rs's line ceiling 800 → 820 (native/tests/file_ceilings.rs): the 8 lines over are the renders_while_capturing field and its default, a saved setting, which is the file's one job.

[ccoventry]

Live test in a throwaway Studio: all three steps pass

Test setup: POST install, HLAE direct-to-video at 2560×1440 and 300 fps, rendered to ProRes 422. Render tab Max Concurrent was 4. Each run captured the same 5 clips (10–11 s each) from wsod25_grp5_h1_m00cat.dem.

1. UI: the options read "1 (about 25% of the CPU)" up to "4 (about 100%)". The labels follow Max Concurrent straight away (at 2: 50/100/100/100). The select is dimmed while Render while capturing is off. The value survives a restart.
2. Renders at once 2: two renders ran together during capture for about 2 min 23 s, at about 25% CPU each. Capture took 4:26; everything was rendered at 18:09. Total CPU while capturing was 65%.
3. Renders at once 1 (baseline): one render at a time during capture. Capture took 4:17; everything was rendered at 16:58. Total CPU while capturing was 53%.

With clips this short, one ProRes render (about 9 min) outlasts the whole capture, so 2 at once didn't finish anything sooner. A longer batch is needed to see renders keep up. The setting does what it says.

Found along the way (none of these come from this PR):

• Kept takes are deleted only when the whole render batch ends, not as each clip finishes (Render and clean up clips while a capture batch is still running, so a long batch never fills the drive #861 behaviour).
• The toast says "1 highlight(s) marked Captured" when all 5 became Rendered.

CPU logs are in D:\dodstudio-tests\rwc-1349\.