perf(gpui): reduce screenshot editor startup time

[dovidmoishe]

Screenshot capture now passes retained pixels directly to the editor, avoiding a second PNG decode and showing an initial preview while GPU rendering initializes.

Adds opt-in experiments for preparing the editor window during capture and warming GPU resources. Hidden preparation is limited to Windows/macOS.

With both experiments enabled and warmed up, capture-to-render median fell from 909ms to 483ms (47%) across four samples per mode.

Validation: 63 screenshot-related tests passed. All four Windows modes passed visibility, export, close, and reopen checks, with identical fresh/reopened exports. Native Linux/macOS testing remains outstanding.

Confidence Score: 5/5

The PR appears safe to merge; the previous large-screenshot saving issue is fixed, and no new blocking issues were found.

Summary

Speeds up screenshot editor startup by passing captured pixels directly to the editor.

• Fresh screenshots reach the editor without another PNG decode.
• Screenshot rendering can reuse GPU layers warmed ahead of time.
• The editor window can be prepared while a screenshot is being captured.

No new actionable issues were found. Checks were based on source review; native UI checks and tests were not run.

_{Reviews (2) · Last reviewed commit: "fix(gpui): preserve oversized screenshot..." · Reviewed by Greptile}

[vercel]

@dovidmoishe 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]

Large screenshots are not saved

capture_and_write now rejects images over 16,384 pixels in either direction before saving the PNG, even for save-only and clipboard-only captures. If a window spans enough high-resolution displays to exceed that size, the X11 capture path uses its full physical bounds and reaches this check. Previously the PNG was saved even if the editor could not open it; now the user gets neither a file nor a clipboard image.

Keep the size limit at the editor boundary so larger screenshots can still be saved and copied.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/desktop-gpui/src/screenshot.rs
Line: 204-207

Comment:
**Large screenshots are not saved**

`capture_and_write` now rejects images over 16,384 pixels in either direction before saving the PNG, even for save-only and clipboard-only captures. If a window spans enough high-resolution displays to exceed that size, the X11 capture path uses its full physical bounds and reaches this check. Previously the PNG was saved even if the editor could not open it; now the user gets neither a file nor a clipboard image.

Keep the size limit at the editor boundary so larger screenshots can still be saved and copied.

---

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

[dovidmoishe]

@greptileai

[richiemcilroy]

Thanks for this! The default-path changes look like real wins (no PNG re-decode, GPU device created during capture, raw first frame), and the PNG is fully written before the editor or clipboard sees it. Before we can merge, a few changes:

1. Remove the two opt-in experiments (CAP_GPUI_SCREENSHOT_PREPARE_WINDOW and CAP_GPUI_SCREENSHOT_WARM_LAYERS: the prepared hidden window/bundle, and the process-lifetime WARM_SCREENSHOT_LAYERS that keeps a wgpu device and renderer layers alive and rebuilds them on every editor close). They are off by default, but the prepared bundle has no PNG while the capture runs (a library refresh could list it), and the warm cache is a permanent leak. Keep the default-path wins.
2. Only keep the RGBA copy in write_png when the editor will actually open (it is about 59 MB at 5K even for copy/save-only), and read GeneralSettings once per screenshot instead of three to five synchronous loads on the main thread.
3. Please post default-path before/after numbers on macOS, measured to the first rendered frame rather than window-open, and confirm the raw preview does not flash against the first GPU frame. The 909 → 483 ms headline needs both experiments enabled, and scripts/benchmark-screenshot-startup.ps1 pins them to 0 and times only the window-open log, so it cannot reproduce it. Either change the script to measure the first rendered frame or drop it.
4. Mention in the description that frames rendered for an older edit are now dropped (screenshot_editor.rs around the render-result handling); it reads like a fix, but it is a behaviour change.

Once those are in and Greptile is still at 5/5 we'll run the full CI and merge.