Selection is slightly off

[j-tai]

Flameshot Version

Flameshot v11.0.0 ()
Compiled with Qt 5.15.3
linux: 5.15.15-76051515-generic
org.kde.Platform: 5.15

Installation Type

Flatpak from Flathub

Operating System type and version

Pop!_OS 21.10

Description

When a region is selected to take a screenshot, the selected area is slightly off from where the mouse was dragged

Steps to reproduce

1. Start a screenshot
2. Select the entire screen, i.e. drag from the top-left corner to the bottom-right corner
   → The selected area is not the entire screen. It is missing a few pixels on the left and top sides.

Screenshots or screen recordings

No response

System Information

Pop!_OS 21.10

Reproducible with 1 or 2 monitors

GNOME 40.4.0, Xorg

[mmahmoudian]

I think I know what you are pointing at and I think it is because of the 8 handles around the region that they have a thickness of few pixels.

I don't think this is necessarily a bug though. The region selection is not meant to select an entire monitor, the flameshot screen is designed for that purpose. Nonetheless, you can always use Ctrl-a (select all) to expand the region to the entire visible area. For micro-adjusting the region you can also use the arrow keys and shift-arrow keys as explained in:

https://flameshot.org/docs/guide/key-bindings/

I wonder what @borgmanJeremy and @veracioux think about this

[j-tai]

Here's a screenshot:

There are clearly a couple pixels outside the selection. Also this behaviour didn't occur prior to 11.0.

you can always use Ctrl-a (select all) to expand the region to the entire visible area.

This doesn't allow me to screenshot just 1 monitor.

[j-tai]

Sometimes it's a lot of pixels and very noticeable:

[borgmanJeremy]

Hmm this is tricky. I agree its undesirable but will need to think of a fix. The obvious fix is to include the region directly under the purple border, but I don't think thats what I really want.

I often very precisely use the border to crop a window. I am open to suggestions.

[thiagoa]

I'm also having the same problem. When I start a selection, it unexpectedly shifts on both axes. Another problem is with video glitches, both at the same time. Here's a recording:

simplescreenrecorder-2022-05-25_11.55.03.mp4

My system is:

# X11, not Wayland

$ lspci -k | grep -EA3 'VGA|3D|Display'
0c:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] (rev c1)
        Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Reference RX 5700 XT
        Kernel driver in use: amdgpu
        Kernel modules: amdgpu

$ uname -a
Linux pop-os 5.17.5-76051705-generic #202204271406~1651504840~22.04~63e51bd SMP PREEMPT Mon May 2 15: x86_64 x86_64 x86_64 GNU/Linux

$ flameshot -v
Flameshot v11.0.0 (11.0.0-2 Debian)
Compiled with Qt 5.15.2

[mmahmoudian]

@thiagoa thanks for the video. Looks like a compositor problem. Is it possible for you to try to replicate this in a clean VM?

[Excigma]

I've been having this issue since Version 11 on X11 on Arch - I've noticed this on my previous Arch and Ubuntu installs on the same computer but they're gone now haha

There also is a delay when pressing the hotkey and flameshot showing up which was not present in v0.10.2 - this might be better suited to a new issue? Since then, I've downgraded back to flameshot v0.10.2, but since I've found this issue I may as well report that I am also able to reproduce this.

I'm using bspwm and picom, along with the community/flameshot package. I am able to reproduce both with and without picom running.

Flameshot v0.10.2:

• When pressing the hotkey, flameshot shows up quicky
• Dragging from the left edge of the screen doesn't result in a gap

video-2022-05-27_14.35.48.mp4

Flameshot v11:

• When pressing the hotkey, flameshot takes possibly up to a second to show up - notice the delay between xev showing the printscreen key and flameshot showing up
• When dragging from the edge, there is a gap

video-2022-05-27_14.37.28.mp4

If I drag slowly, the offset isn't as obvious, but when I drag quickly the gap is larger:

video-2022-05-27_14.46.05.mp4

This is obviously extremely unscientific, however, I'm using a trackpad to drag - by double-tapping then dragging with 1 finger only, this should mean that I am not starting to click down/drag after my mouse has started moving

[veracioux]

Please check if #2630 resolves the issue.

[Excigma]

Ay, sure does fix it for me

video-2022-05-28_12.07.30.mp4