flameshot gui mirrors screen on-screen when invoked

[shawnyeager]

Flameshot Version

Flameshot v12.1.0 (-)
Compiled with Qt 5.15.14
via Arch AUR

Installation Type

User repository (AUR)

Operating System type and version

Arch

Description

This began over the past few days. As Arch is a rolling release, I can't pin it down, whether a recent build of mutter or a component of Gnome.

See screenshot.

Steps to reproduce

1. Invoke flameshot gui via Gnome keyboard shortcut
2. Observe that screen has been duplicated on-screen at ~80% scale
3. Otherwise, functions normally

Screenshots or screen recordings

System Information

OS: Arch (rolling, current)
Linux framework 6.13.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 08 Feb 2025 18:54:55 +0000 x86_64 GNU/Linux

Display: Framework 13" 2.8k

Desktop Environment: Gnome 47.4 @ 175% fractional scaling

[shawnyeager]

Update: I just tested this on an external display @ 100% (no fractional scaling), and the behavior is normal/as expected. So, given that fractional scaling is experimental, maybe this a non-issue for now.

[mmahmoudian]

Yes, this is already reported and is an known issue that fractional scaling would break how Flameshot displays the captured screen. Perhaps Gnome is new to the game as KDE have had this issue for quite some time already.

This is not intuitive to fix when considering multi-monitor setup with various scaling factors in arbitrary arrangements. This is how Flameshot works:

1. When triggered, it requests a screenshot from the compositor
2. It tries to have a fullscreen borderless opaque window above everything else
3. Load the annotation tools and etc.

Now, when we have a multi-monitor setup with various scaling factors, we are practically left with one choice as far as I can think of: open a borderless fullscreen window on every monitor and show the content in accordance to the monitors' specifications. In X11 that's not a big deal, but in Wayland that's a bit of an issue. Now, to all this mess, add the situation that the user wants to crop a part that is shared across two of the monitors. Not only should we sync the position of the selection area between two or more Flameshot windows, but we have to later combine the resulting images from all the Flameshot windows, scale them to be on the same level of scale, and attach them together with a perfect alignment to result in a clean uniform image. And to add to all this complexity, add the way Gnome is treating other developers and how much of an access the Gnome public API has compared to their private API.

Anyways, this is a duplicate issue, and should be closed in favor of the earlier one. I will keep this open until I get behind a computer and can find that issue number.

Thanks again for reporting this. It is good that our users are willing to help and point out issues.

[Lorak-mmk]

This is not intuitive to fix when considering multi-monitor setup with various scaling factors in arbitrary arrangements. This is how Flameshot works:

@mmahmoudian As you explained, handling multiple monitors with various scaling factors is extremely hard.

99.9% of the screenshots I take are of some part of a single display, even if multiple displays are connected - I suspect it is the same for many (most?) other people.
For that use case, it would be enough to have an option for flameshot gui to limit it to the display that the cursor is on, instead of all the displays simultaneously.
Intuition tells me adding such option should be much simpler than handling arbitrary multi-display setups, but I don't know the codebase of flameshot at all, so it may be totally wrong. WDYT?