[Feature Request]: "Freeze screen" visually when triggering area screenshots

[dennyschroeder]

Hi @richiemcilroy,

First of all, congratulations on the amazing work with Cap! The UI and the integration with Linear are incredibly clean and well-structured.
I am currently testing Cap as a 2-in-1 tool for both video recording and screenshots to minimize the number of active background apps running on my Mac. While the core experience is great, I encounter a few workflow blockers when using the Area Screenshot Tool for professional feedback (especially when reporting bugs on GitHub).

I would love to see the following options/improvements to make the screenshot process more seamless and performance-oriented:

When triggering an area screenshot while a video (e.g., YouTube) is running or an active dropdown menu is open, the content often continues to move or closes before the selection is made.

Proposed Solution:
Implement a visual "freeze frame" the moment the screenshot shortcut is triggered (while audio/video can keep playing in the background). This ensures users can precisely capture the exact frame they intended without moving elements shifting out of bounds during the area selection.

Thank you for considering this feedback, Richie! Looking forward to replacing my standalone screenshot utilities entirely with Cap.

[linear]

CAP-713

[tembo]

Thanks for this thoughtful feature request! The freeze-frame approach would definitely improve the area screenshot experience when capturing dynamic content.

Looking at the current implementation, the area screenshot workflow is:

1. User triggers the ScreenshotArea hotkey (in apps/desktop/src-tauri/src/hotkeys.rs:238-249)
2. This opens the capture area picker (apps/desktop/src/routes/capture-area.tsx) where users drag to select a region
3. After confirming the selection, take_screenshot() in apps/desktop/src-tauri/src/recording.rs:1986 is called with an Area target
4. The actual capture happens via capture_screenshot() in crates/recording/src/screenshot.rs, which uses platform APIs (CGDisplayCreateImageForRect on macOS, Windows.Graphics.Capture or GDI on Windows)

The delay between opening the area selector and the actual capture is where moving content can shift, as you've described.

For implementation, there are a couple of approaches to consider:

Option A: Capture-first, then select region - Take a full display screenshot immediately when the hotkey is triggered, then let the user select a region from the frozen image. This is how macOS's native screenshot tool works. The existing try_fast_capture() function in screenshot.rs:234 (macOS) and screenshot.rs:747 (Windows) could be used to grab the initial frame, then the area picker would operate on that static image rather than the live screen.

Option B: Overlay a frozen frame - Capture a full-screen image when entering area selection mode and display it as a fullscreen overlay while the user makes their selection. This would require modifications to the CaptureArea component to show the frozen frame instead of the transparent overlay.

Option A would likely be simpler since it reuses the existing screenshot capture pipeline and just changes when the capture happens relative to the selection UI. The crop logic is already in place (crop_area_if_needed() at screenshot.rs:1094-1141).

Related issues that touch similar UX concerns: #1698 (screenshot tool polish on Windows) and #1733 (OCR/text copy from screenshots, recently merged as #1799).