[shaileshvats]

Summary

cap_gpui_kernels::frame::copy_rows builds the BGRA buffer behind every non-macOS camera preview frame (feeds::camera_preview_image, mirrored by default) and the decoded-frame buffers for library thumbnails, imports and clip thumbnails. It allocated its output with vec![0; len] and then overwrote every byte, so each call wrote the whole frame twice.

This PR writes each output byte exactly once:

• Not mirrored: Vec::with_capacity plus one extend_from_slice per row, so there's no zero-fill pass.
• Mirrored: pixels are reversed straight into the vector's spare capacity using as_chunks::<4>(), then a single set_len. This is the same spare-capacity pattern unpad_rgba_to_bgra already uses. The row reversal stays a zip(... .rev()) over [u8; 4] chunks, which LLVM vectorizes. An indexed source[last - i] loop measured about 4× slower, so I didn't use one.
• Output is byte-for-byte identical, including the zeroed tail bytes when a mirrored row_bytes isn't a multiple of 4, and every None case is unchanged.

This doesn't overlap with #2668. That PR adds a fast path for unpadded, non-mirrored frames, but it keeps the zero-fill for padded rows and for the mirrored camera path that this PR targets.

Benchmarks

New benches/frame_copy_rows.rs, in the same style as frame_unpad: the old implementation is inlined as baseline, outputs are asserted equal, before/after runs alternate within one build, 5 warmup and 30 measured samples per workload. Strides are padded the way ffmpeg/wgpu pad them (64- or 256-byte aligned).

Apple M2, rustc 1.99.1, cargo bench -p cap-gpui-kernels --bench frame_copy_rows. Median of 30 samples; speedup range across three separate runs:

workload	before	after	speedup (3 runs)
camera-720p-mirrored	0.163 ms	0.127 ms	1.28–1.42x
camera-1080p-mirrored	0.356 ms	0.257 ms	1.38–1.52x
camera-720p	0.107 ms	0.076 ms	1.40–1.46x
camera-1080p	0.288 ms	0.192 ms	1.42–1.51x
import-4k-rgba	1.448 ms	0.990 ms	1.46–1.50x
library-thumb-rgb24	0.091 ms	0.055 ms	1.59–1.67x
clip-thumb-bgra-padded (1366x768, 256-aligned)	0.183 ms	0.121 ms	1.51–1.57x

At 30 fps, a mirrored 1080p camera preview spends about 3 ms less per second in this copy.

Testing

• New copy_rows_matches_a_zeroed_copy_for_every_shape checks the new code against the old zero-then-copy behaviour. It covers zero rows, zero row_bytes with zero and non-zero stride, tight and padded strides, RGB24 rows, rows that aren't a multiple of 4 (mirrored and not), and a 256-byte-aligned BGRA stride.
• cargo test -p cap-gpui-kernels --lib frame::: 11 passed.
• rustfmt --check is clean on the touched files.
• cargo clippy -D warnings: the touched code is clean. Stable clippy 1.99 still flags the existing swap_red_blue (chunks_exact_mut(4)), which this PR doesn't change.

I couldn't run the full desktop-gpui workspace locally: [patch."https://github.com/wingleeio/zed"] points at a sibling zed-cap checkout, and cap-audio needs system ffmpeg. So I built and tested the frame module and this bench in a standalone crate with the same release profile (lto = "thin", codegen-units = 1).

Confidence Score: 5/5

The PR appears safe to merge; no actionable issues were found.

Summary

copy_rows avoids zero-filling its output before copying frame bytes.

• Frame copies build packed image buffers without a zero-fill pass.

No actionable issues found. Build and test commands were not run during this review.

_{Reviews (1) · Last reviewed commit: "perf(desktop-gpui): write copy_rows outp..." · Reviewed by Greptile}

[vercel]

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

A member of the Team first needs to authorize it.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.