[Bug]:

[martin152]

Pre-submission Checklist

• I have attached the bug report file generated by the app (camera-bug-report-*.md)
• I have searched existing issues to make sure this bug hasn't been reported
• I am using the latest version of Camera
• I have tried restarting the application

Bug Description

The Photo/Video mode toggle (ModeCarousel) expansion animation causes ~80% GPU utilization on hardware Vulkan (RADV). The same animation on software Vulkan (lavapipe) produces identical visual output at ~7–8% GPU — a 10:1 cost ratio for the same work. The GPU spike is present regardless of whether a camera is connected.

A secondary symptom: when no camera is streaming (GPU otherwise idle), the spike is large enough to electromagnetically couple into the camera module's VCM coil, producing an audible buzz. This disappears when a camera is streaming because the GPU baseline is already elevated, but the underlying GPU overuse remains in both cases.

Steps to Reproduce

Open COSMIC Camera (camera connected or not)
Monitor GPU: watch -n 0.1 cat /sys/class/drm/card1/device/gpu_busy_percent
Hover over the Photo/Video toggle

Expected Behavior

GPU usage comparable to other UI animations (~10–20%)

Bug Report File

camera-bug-report-20260514_043659.md

Additional Context

No response

[FreddyFunk]

Thanks for the report! I tried to draft a fix that would reduce redraws during the carousel animation which should reduce the GPU load on high refresh rate displays especially. Are you able to compile and test the following branch on your system and see if it helps?
fix/carousel-poll-redraw

More details are in this pull request draft:
#413

[martin152]

Thank you lots for taking the time to look into this, results of the test and some system info:

Tested PR #413 (fix/carousel-poll-redraw) -- results:

Built from source on Linux Mint 22.3, AMD Radeon integrated GPU (Cezanne), 60Hz display.

Flatpak v0.3.4 (baseline): 80-90% GPU on hover animation
PR #413 branch: ~60% GPU on hover, ~70% on mode switch

The fix noticeably reduces the total duration of unnecessary GPU load by eliminating vsync-rate polling during idle timer waits (hold-to-expand, hover-leave delay, stage1-collapse-after-stage2). However, the active animation phases (the 300ms ease-out-cubic expand/collapse transitions) still call shell.request_redraw() every frame via the tick_animations() -> request_redraw() loop in update(), which I think accounts for the remaining 60-70% GPU spike.

For reference, other apps with comparable UI animations on this hardware peak at around 20% GPU.

Separate issue on main: The app picks up the IR camera sensor (Integrated I, pixel format R8) as a selectable camera. Switching to it crashes the app -- the QR detector at qr_detector.rs:104 hits an index-out-of-bounds because R8 is single-channel, and then wgpu::Queue::write_texture fails with "bytes per row is less than the number of bytes in a complete row." The crash persists across restarts because the selected camera is saved to config.

[FreddyFunk]

@martin152 thanks for the confirmation. I merged #413 now so it will be included in the next release.
The remaining GPU spike is then intentional. I want to have this animation smooth and not capped to 30 fps or similar like a lot of animation engines do. Capping it reduces the GPU usage, but it feels very stutter to me since I am used to 240 hz on a high refresh rate monitor.

Also thanks for bringing up the crash with the IR camera sensor. I forgot to wire up some grayscale pixel formats. Can you test #430 ? It should hopefully fix the issue.