[Bug]: SnapShot animation leaves an oversized bar on Hyprland

[AksharP5]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. On Omarchy / Hyprland 0.56.2, enable SnapShots and Capture animations in the desktop app.
2. Capture another app on the same monitor as T3 Code.
3. Repeat with the captured app on another monitor.
4. Watch the screenshot shrink into the composer before the animation overlay disappears.

Expected behavior

The overlay shrinks to the attachment bounds without drawing outside the thumbnail.

Actual behavior

The thumbnail shrinks, but an oversized solid rectangle remains behind it until the overlay is removed. On the same monitor it can be wide; across monitors it can become a narrow vertical strip. The reported bar is black. A synthetic checkerboard with a white border reproduces a white rectangle, so the color depends on the image.

The finished attachment is correct. This affects the temporary animation only.

Impact

Cosmetic issue

Version or commit

Introduced with #8103. Reproduced with the installed Nightly helper and a helper built from main at 8588d7f.

Environment

Omarchy 4 development branch, Hyprland 0.56.2, native Wayland. Two 1920x1080 monitors at scale 1.

Investigation

The helper updates the viewport size without reattaching its unchanged image buffer. Hyprland 0.56.2 copies the surface size only on a buffer update, leaving the previous dimensions around the newly scaled image. Reattaching the same buffer during resizing removes the artifact in both same-monitor and cross-monitor replay tests.

Workaround

Turn off Capture animations in Settings > SnapShots.

[juliusmarminge]

Triage

Confirmed as a cosmetic Hyprland-only bug in the SnapShot capture-animation overlay. The finished attachment is correct; only the temporary helper overlay is wrong.

What we see in tree

The Hyprland helper (native/hyprland-snap-shot/src/feedback.rs, Feedback::draw) scales the overlay with wp_viewport.set_destination and moves the subsurface, but reattaches the shared-memory buffer only when the texture kind changes (flash vs image). Flight frames skip attach on purpose to avoid rewriting pixel buffers.

That matches the report: Hyprland 0.56.2 updates surface size on buffer attach, so the previous dimensions stay painted around the newly scaled thumbnail. Same-monitor leftover can be wide; cross-monitor leftover can be a thin strip. Color comes from the image, which is why a white-bordered synthetic capture shows a white rectangle.

Desktop wiring looks fine:

• apps/desktop/src/snapShot/HyprlandSnapShot.ts starts the helper
• apps/desktop/src/snapShot/NativeCaptureFeedback.ts sends animate / waits for landed

Electron SnapShotTransition and the KDE/GNOME helpers are a different path.

Related

• Introduced with feat(desktop): add cross-platform window capture #8103
• No duplicate issue found
• Workaround: Settings → SnapShots → turn off Capture animations

Suggested fix

Reattach the current image/flash wl_buffer whenever the viewport destination size changes (or on every flight frame), not only on texture kind change. Rebuild t3-hyprland-snap-shot and re-check same-monitor and cross-monitor on Hyprland 0.56.2.

Leaving this open as an accepted Linux helper bug.

[juliusmarminge]

Thanks for the detailed repro and the helper-side diagnosis.

This looks like a real cosmetic bug in the Hyprland SnapShot overlay, introduced with #8103. The finished attachment is fine; only the temporary capture animation is wrong.

The Hyprland helper (native/hyprland-snap-shot/src/feedback.rs) scales the overlay with wp_viewport and moves the subsurface, but it reattaches the shm buffer only when the texture changes (flash vs image). Flight frames skip that attach on purpose. On Hyprland 0.56.2 that leaves the previous surface size around the newly scaled thumbnail — a wide leftover on the same monitor, a narrow strip across monitors. Color follows the image, which matches the leftover being stale compositor surface contents rather than a hardcoded bar.

KDE/GNOME use different feedback paths and are not implicated. Workaround remains: Settings → SnapShots → turn off Capture animations.

Next step: reattach the current buffer on resize commits in the Hyprland helper (or at least whenever the viewport destination changes), then reinstall/update the bundled helper and re-check same-monitor and cross-monitor captures on Hyprland 0.56.2. This is a compositor quirk we can work around; we should not wait on an upstream Hyprland fix.

[AksharP5]

Implemented in #10646. The attached helper replay reproduces the wide same-monitor rectangle and narrow cross-monitor strip before the patch, then shows clean thumbnails with the fix. All 10 helper tests pass.

hyprland-overlay-before-after.mp4