[JeffreyLin1]

Editing a long recording that has zoom segments gets slower the further the playhead is into it. On every slider tick, GPUI's publish_project sends the edited project and asks for the paused frame again, and the preview renderer throws away its zoom timelines and simulates them from 0:00 up to the playhead. Playback does the same when you press play or edit while playing. #2476 fixed this for scrubbing, but edits still pay for a full rebuild, and any edit to the zooms themselves has to rebuild anyway. #2507 skips the cursor rebuild on unrelated edits but still rebuilds zoom timelines, so it doesn't overlap with this.

Most of the rebuild was repeated work, so this PR makes it cheaper without changing what it computes:

• targets_at scanned every zoom segment twice on each 8 ms step, and a 30 minute recording has 225k steps. A small index now finds the active segment with binary search, using the same first-match (start, end] rule.
• Every auto segment filtered every cursor move in the recording to build its clusters. When the moves are in time order, binary search narrows each slice first and the same filters run on it. Unordered input falls back to the full scan.
• The spring solver recomputed its exp/sin/cos terms on every step, even though they only change with the step length and the spring constants. Each simulation now caches them.

Output is bit-identical. The benchmark hashes every sample and all scenarios match main, and the new tests compare each fast path against the old scan. I also ran 20,000 random projects through both versions (the old copy isn't committed) and every sample matched.

Results

The new live-edit-benchmark example drives EditorInstance with the GPUI app's preview settings and drags the padding slider while paused, 60 edits at each position. The project is a synthetic 30 minute 1080p recording with 60 Hz cursor data and 60 auto zooms. Apple M3 Pro, release build, before and after runs interleaved, median of 3.

Edit while paused at	Before	After
0:36	8.6 ms	2.9 ms
15:00	18.9 ms	5.6 ms
29:24	28.7 ms	8.4 ms
CPU time over 180 edits	2.97 s	0.63 s

Near the end of that recording a slider drag now fits in a 60 Hz frame. On a 10 minute recording with 20 zooms the median edit goes from 6.6 to 4.3 ms, and recordings of a few minutes only save a millisecond or two.

Timing just the rebuild (benchmark_zoom_timeline_rebuild) with the playhead at the end gives 30.4 -> 6.4 ms for 30 minutes with 60 zooms and 104 -> 13.7 ms for 60 minutes with 120. The existing benchmark_long_recording_zoom_startup also runs about twice as fast.

Reproduce

cargo test -p cap-rendering --release --lib benchmark_zoom_timeline_rebuild -- --ignored --nocapture
cd apps/desktop-gpui && cargo run --release --example live-edit-benchmark -- /path/to/copy-of-project.cap

Point the example at a copy, since the editor can write project-config.json back into the project. cargo test -p cap-rendering, clippy and fmt all pass.

Confidence Score: 5/5

The PR appears safe to merge, with the previous test concern addressed and no new actionable issues found.

Summary

Speeds up zoom timeline rebuilds with a segment index, narrower cursor searches, and cached spring calculations. Adds a live-edit benchmark.

• Zoom timelines find active segments and cursor moves with shorter searches.
• Spring steps reuse calculations when their settings stay the same.
• Benchmarks show rebuild and live-edit times at different playhead positions.

_{Reviews (2) · Last reviewed commit: "test(rendering): check cached spring ste..." · Reviewed by Greptile}

[vercel]

Someone is attempting to deploy a commit to the Cap Software Inc Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Spring test shares its solver

cached_spring_steps_match_fresh_simulations compares two instances that both use the new solver. It checks cache reuse, but a mistake in the moved spring formulas would affect both sides and still pass. Keep the original solver as a test-only reference, or assert saved baseline results, so the promised bit-identical output has a lasting regression check.

Prompt To Fix With AI

This is a comment left during a code review.
Path: crates/rendering/src/spring_mass_damper.rs
Line: 281-289

Comment:
**Spring test shares its solver**

`cached_spring_steps_match_fresh_simulations` compares two instances that both use the new solver. It checks cache reuse, but a mistake in the moved spring formulas would affect both sides and still pass. Keep the original solver as a test-only reference, or assert saved baseline results, so the promised bit-identical output has a lasting regression check.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[JeffreyLin1]

@greptile

[richiemcilroy]

Thanks so much!