perf(desktop-gpui): resize picker thumbnails up to 4.3x faster with identical output

[Theophilus2003]

Summary

On Windows and Linux, every recording-picker thumbnail is a full-resolution screenshot of a display or window that fit_centered shrinks to 320×180 with image::imageops::resize(.., Lanczos3). That resize costs 124 ms per 4K display and 49 ms per 1440p display, once per display and window in every thumbnail sweep the picker runs. macOS isn't affected: ScreenCaptureKit captures at 320×180 already.

This replaces the call with a Lanczos3 resize in cap-gpui-kernels that is byte-identical to image's and 2.9x to 4.3x faster on screen-sized sources.

How

image's resize runs a vertical pass (into an Rgba32F buffer) and then a horizontal pass. Every tap goes through a generic get_pixel and four NumCast conversions, iterating one output pixel at a time down a column.

resize_lanczos3 keeps the arithmetic identical:

• the same sinc/lanczos3 kernel, the same tap window (floor/ceil/clamp) and the same weight normalisation;
• the same per-pixel f32 accumulation order (taps ascending, starting from 0.0, vertical pass first);
• the same clamp and round back to u8.

Only the loop order changes. The vertical pass walks each output row in 32-float blocks that stay in registers, with all taps accumulated before moving on, so it vectorizes. Each output value still sees the same sequence of additions, and Rust never fuses them into FMA, so the result is bit-for-bit the same.

On x86 the vertical pass runs under #[target_feature(enable = "avx2")] when is_x86_feature_detected!("avx2"), the same dispatch crates/rendering/src/cpu_yuv.rs uses. Everything else runs the portable path, which is the identical code compiled for the baseline target.

Benchmarks

cargo bench -p cap-gpui-kernels --bench thumbnail_fit, the existing benchmark with five screen-sized workloads added. Each row is the median of 30 alternating samples, 8 fits each. "Before" is the benchmark's existing baseline (imageops::resize with Lanczos3). x86_64 Linux, 4 vCPU with AVX2.

Source	Before	After	Speedup
1600×1000 window	20.78 ms	7.08 ms	2.9x
1920×1080	25.32 ms	8.76 ms	2.9x
2560×1440 display	48.85 ms	13.89 ms	3.5x
3440×1440 ultrawide	67.13 ms	18.31 ms	3.7x
3840×2160 display	124.21 ms	29.15 ms	4.3x
3840×2160 display, mixed alpha	125.10 ms	28.95 ms	4.3x
640×360	4.78 ms	2.87 ms	1.7x

Without AVX2 the portable path measured about 49 ms for the 4K case (≈2.5x). The benchmark asserts that its baseline and fit_centered produce equal images for every workload before it times them.

Tests

• New lanczos3_matches_image_resize_byte_for_byte: random RGBA noise, including alpha, at 3840×2160, 2560×1600, 1920×1080, 1366×768, odd window sizes, an upscale and 1-pixel strips. Every case must equal image::imageops::resize(.., Lanczos3) exactly.
• New portable_vertical_pass_matches_the_dispatched_one: the AVX2 and portable vertical passes produce bit-identical f32 buffers.
• The existing resized_sources_match_lanczos_reference and the other fit_centered tests pass unchanged.
• cargo test -p cap-gpui-kernels (28 passed), cargo clippy -p cap-gpui-kernels --all-targets -- -D warnings, rustfmt clean.

Confidence Score: 5/5

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

Summary

Replaces thumbnail resizing with a custom Lanczos3 implementation that works through rows in blocks and selects AVX2 when available.

• Large screenshots resize into thumbnails faster with the same pixels.

_{Reviews (1) · Last reviewed commit: "perf(desktop-gpui): resize picker thumbn..." · Reviewed by Greptile}

[vercel]

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

A member of the Team first needs to authorize it.