perf(desktop-gpui): read and decode the screenshot clipboard image off the UI thread

[celeroncoder]

The Linux arm was built and tested locally. The macOS and Windows arms were written in the same shape and verified by reading, since I don't have access to macOS or Windows machines; CI has since built the GPUI desktop app on aarch64 and x86_64 macOS, Windows and Linux and run the macOS and Windows test jobs, all green, so this is out of draft.

After a screenshot, screenshot_finished copied the image to the clipboard on the UI thread: std::fs::read of the full-resolution PNG (tens of MB on a Retina display), then per platform the clipboard conversion, right when the tray, library and editor are also refreshing. On Linux that was a format sniff, bytes.to_vec(), a content hash and another clone inside ClipboardItem::new_image; on Windows a full RustImageData::from_bytes decode; on macOS NSData + NSImage + the pasteboard write.

Change

copy_image_to_clipboard(path, cx) now returns a Task: the file read and prepare_clipboard_image run on the background executor, and only write_clipboard_image runs on the UI thread. Each platform module exports the same three items (ClipboardImage, prepare_clipboard_image, write_clipboard_image):

• Linux: prepare sniffs the format and builds the ClipboardItem from the owned bytes (no to_vec(), no new_image clone; the hash runs in the background). Write is try_write_to_clipboard.
• Windows: prepare does the RustImageData::from_bytes decode in the background (RustImageData is {u32, u32, Option<DynamicImage>}, so it is Send). ClipboardContext::new and set_image stay on the UI thread.
• macOS: only the file read moves; NSData, NSImage and the pasteboard write stay on the main thread, same body as before.

Error strings are unchanged. The same treatment is applied to the library "Copy" action, the settings "Copy" action and the editor's export-to-clipboard; the editor's success toast still fires only after the write succeeds. Nothing after screenshot_finished reads the clipboard, so the only observable change is that the clipboard is populated a few milliseconds after the editor opens instead of before.

Results

Linux, debug build (dependencies at opt-level 2), synthetic 5120×2880 PNG of 27.8 MB, medians of 5 runs, 2 vCPU aarch64 Linux box.

	main @ 2a61427	This PR
UI-thread work before the clipboard write	48.0 ms (file read alone 8.7 ms)	0 ms
Background prepare	—	14.4 ms

The try_write_to_clipboard call itself is unchanged and not included. On Windows, set_image still re-encodes to PNG and BMP on the UI thread; that is the largest remaining cost there and is out of scope here. macOS keeps its AppKit main-thread work by design.

Overlap

• speed up copy to clipboard #320 (open issue, "speed up copy to clipboard") is the user-visible complaint this addresses on the GPUI app; [Feature Request]: Customizable "After Capture" behaviors for Screenshots (Toggle Editor, Clipboard, and Auto-Save) #1860 (open) configures the same after-capture copy path.
• perf(gpui): reduce screenshot editor startup time #2703 (open, screenshot editor startup) and perf(rendering): share the project config across frame uniforms #2483 (open) touch screenshot_editor.rs / app_windows.rs; both apply cleanly on top of this branch. perf(desktop-gpui): encode screenshot save and copy with the parallel PNG writer #2717 (open, parallel PNG writer) speeds up the encode half of copy in kernels/ and doesn't overlap.
• fix(desktop): retry transient clipboard image writes #2189 (open) is the Tauri app's clipboard retry (src-tauri/automation.rs); same domain, no shared code.
• feat(desktop-gpui): reliable shortcuts with after-capture choices #2559 (merged) added the after-capture behaviours this path reads; already in main.
• fix(desktop-gpui): request the Instant link while the capture is built on macOS #2592, feat: add imported media tracks and editor waveforms #2308 and feat: desktop design system, stabilization and dependency migration #2587 touch these files but already fail to apply on current main.

How this was made

This PR is agent-generated.

• The finding comes from an audit of main by OpenCode scouts and Gemini 3.8 Flash, re-checked against the source by the orchestrating Claude session.
• Claude Opus 5.5 wrote the change on current main, checked clipboard_rs for Send, and took the Linux measurement above.
• Gemini 3.8 Flash (Antigravity) reviewed the diff independently: it confirmed the Send bounds from the clipboard_rs and gpui sources, the identical signatures across the three platform modules, that every task is detached and every toast fires after the write, re-ran cargo check, clippy and the platform:: tests on Linux, and approved. Neither agent had a macOS or Windows machine to build on.

🤖 Generated with Claude Code

Confidence Score: 4/5

Fix clipboard request ordering before merging so users reliably paste the screenshot they copied last.

Findings

1.  Older copies replace newer ones ▶

Fix with agent prompt

### Issue 1
apps/desktop-gpui/src/platform.rs:565-574
`copy_image_to_clipboard` now writes in the order background work finishes, not the order users click Copy. The library leaves its Copy buttons active and detaches every request. If a user copies a large screenshot and then a smaller one while the first is still preparing, the older request can finish last and replace the newer image. Track request order and skip stale writes, or queue the copies so an older request cannot overwrite a newer one.

---

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

Summary

Moves screenshot file reads and image preparation off the UI thread.

• Screenshot copies prepare image data off the UI thread.

_{Reviews (1) · Last reviewed commit: "perf(desktop-gpui): read and decode the ..." · Reviewed by Greptile}

[vercel]

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

A member of the Team first needs to authorize it.

[celeroncoder]

cc @richiemcilroy for review (GitHub doesn't let a fork request reviewers, so tagging instead).

[greptile-apps]

Older copies replace newer ones

copy_image_to_clipboard now writes in the order background work finishes, not the order users click Copy. The library leaves its Copy buttons active and detaches every request. If a user copies a large screenshot and then a smaller one while the first is still preparing, the older request can finish last and replace the newer image. Track request order and skip stale writes, or queue the copies so an older request cannot overwrite a newer one.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/desktop-gpui/src/platform.rs
Line: 565-574

Comment:
**Older copies replace newer ones**

`copy_image_to_clipboard` now writes in the order background work finishes, not the order users click Copy. The library leaves its Copy buttons active and detaches every request. If a user copies a large screenshot and then a smaller one while the first is still preparing, the older request can finish last and replace the newer image. Track request order and skip stale writes, or queue the copies so an older request cannot overwrite a newer one.

---

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