Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bad behavior on wayland with fractional scaling #748

Open
duvh93 opened this issue May 16, 2020 · 25 comments
Open

Bad behavior on wayland with fractional scaling #748

duvh93 opened this issue May 16, 2020 · 25 comments
Labels
Bug It's a bug Linux Linux specific issue

Comments

@duvh93
Copy link

duvh93 commented May 16, 2020

Flameshot version
Flameshot v0.6.0
Compiled with Qt 5.14.1

Describe the bug
I take a screenshot from terminal with "flameshot gui" and the resulting file is a zoomed blurred version of what I actually see on my screen.

To Reproduce
Use an HiDPI screen, set wayland to fractional scaling value (e.g. 125%), use qt5-wayland and export the env var QT_QPA_PLATFORM=wayland, take a screenshot with flameshot gui

Expected behavior
What I get should be what I see

What I am getting
2020-05-16_13-24

What I can see (and get with gnome screenshot binding)
Screenshot from 2020-05-16 13-24-23

@mmahmoudian mmahmoudian added Bug It's a bug Linux Linux specific issue Wayland Wayland specific issues labels Sep 6, 2020
@duvh93
Copy link
Author

duvh93 commented Sep 14, 2020

I managed to trace back the bug source and wanted to report back.

As fractional scaling (1.25) is enabled, my screen (2560x1440) is seen by Qt at its scaled resolution (2048x1152).

When I ask to "Take Screenshot", the ScreenGrabber calls Gnome via dbus to save a screenshot of the entire desktop into a temporary file which is saved at screen physical resolution (2560x1440). Then the surface is loaded from filesystem and returned back as a Qpixmap to the CaptureWidget constructor and stored in m_context.origScreenshot and m_context.screenshot.

When it's the time to show the image on screen, Qt displays an unscaled 2560x1440 surface on a virtually 2040x1152 screen and this leads to the cropping I was complaining about.

Now, I've tried to work this around by scaling the surface m_context.screenshot in the constructor via the scaled(W,H,...) method where (W,H) are retrieved from Qt information on screen geometry. This works but the resulting image is obviously far from sharp because of the scaling process.
I don't know whether we can get a sharp 1:1 image to be annotated on screen but I am confident that at least in the export routines the good image quality can be retrieved by mean of m_context.origScreenshot. It will just be a matter of reapplying all the tools in sequence with their coordinates/sizes correctly scaled back for coherence with the physical size.

I've also noticed that copying to the clipboard is broken on wayland, I only get garbage when pasting onto another client. But I'll open another issue for this.

@holazt
Copy link
Collaborator

holazt commented Sep 21, 2020

This issue still exists in 0.8.0.

@borgmanJeremy
Copy link
Contributor

This may be fixed from: e1214e2

@duvh93
Copy link
Author

duvh93 commented Sep 26, 2020

Unfortunately it is not :(

Flameshot:

2020-09-26_19-38

Gnome Screenshot:
Screenshot from 2020-09-26 19-42-35

Same thing is also happening on my 27" monitor which is not HiDPI...

@borgmanJeremy
Copy link
Contributor

This actually good news because I also have a 27in non hidpi monitor so I should be able to recreate it. Thanks for reporting back

@borgmanJeremy
Copy link
Contributor

borgmanJeremy commented Oct 28, 2020

@duvh93 Thanks for your detailed report. I can confirm your analysis is spot on as to what the issue is. This is an article Qt has which is pretty relevant explaining the difference between "Device Pixels" and "Device Independent Pixels".

As a first fix I think downsampling the raw image by the scaling factor would work okay. I know this would throw some pixels away, but is this really noticeable on an annotated screenshot?

A better fix would be to have QT draw the widget using device pixels instead of device independent pixels, but so far I haven't found a place in QT do do that.

Edit: Actually simply resizing the pixmap will not work. The entire widget needs scaled. This is obvious when you see that the help text and side bar are also cropped. hrmmmmm

@borgmanJeremy
Copy link
Contributor

Final comment for the night, this is not actually a wayland issue but a general issue with fractional scaling. Now that KDE supports fractional scaling on X, I can create the same issue on X.

@MarshmelloSUCKS
Copy link

It's happening to me at 125%, but when I use it, my display resolution switches to something lower and flips back to normal for a short period of time. Keeps looping while in Flameshot. I use Wayland

@phil-nelson
Copy link

I'm having what I think is the same issue, using wayland. My laptop screen is 200% scaling and I have an external monitor at 100%. When I try to use flameshot I get an extremely "zoomed in" section of the screens so I can't use it 😞

@idarlund
Copy link

idarlund commented Sep 2, 2021

I also have a similar issue. Wayland with 1.25 fractional scaling. When starting flameshot gui to take a screenshot, my screen zooms in so the bottom part and the right part of the screen is "outside" of the monitor.

@bitsar
Copy link

bitsar commented Nov 30, 2021

Same issue here with fractional scaling on 4K display - unusable.
Suck a shame as Flameshot has been my go to for years.
Will reinstall once fixed

@smarinel
Copy link

smarinel commented Jan 2, 2022

Just came by to report I have the same issue using Ubuntu 21.04 on a laptop with fractional scaling.

@duvh93
Copy link
Author

duvh93 commented May 8, 2022

Any update?

@mmahmoudian
Copy link
Member

@duvh93 this is not yet fully resolved, but people have suggested some workarounds that have solved the issue. Perhaps the best description can be found here:

#564 (comment)

@rayzorben
Copy link

@mmahmoudian it seems that the workarounds only work for KDE, am I correct in that assumption? I tried the one you linked to on Gnome 42 and it doesn't seem to solve it.

Is there another workaround for Gnome?

@mmahmoudian
Copy link
Member

@rayzorben Fractional scaling on multi-monitor setup are still an issue (if that is the issue you are facing). but Gnome >=41 people typically forget to install xdg-desktop-portal-gnome which is a remedy for other types of issues.

@rayzorben
Copy link

@mmahmoudian I installed xdg-desktop-portal-gnome and rebooted, and it didn't fix it. I am not experiencing an issue with fractional scaling on multi-monitor setup. I have a single monitor, laptop, and I am having fractional scaling issues. As in, I have my scaling set to 125%, and when I use flameshot I lose 25% off the bottom and right of the screen.

@jaysonwcs
Copy link

@mmahmoudian I installed xdg-desktop-portal-gnome and rebooted, and it didn't fix it. I am not experiencing an issue with fractional scaling on multi-monitor setup. I have a single monitor, laptop, and I am having fractional scaling issues. As in, I have my scaling set to 125%, and when I use flameshot I lose 25% off the bottom and right of the screen.

Exactly the same issue with me :(

@crifan
Copy link

crifan commented Oct 9, 2022

Finally fixed by change flameshot shortcut from:
flameshot gui
to
env QT_AUTO_SCREEN_SCALE_FACTOR=1.5 flameshot gui
in which, 1.5 --->>> Settings->Display->Scale: 150%

@duvh93
Copy link
Author

duvh93 commented Oct 11, 2022

env QT_AUTO_SCREEN_SCALE_FACTOR=1.5 flameshot gui

Still it doesn't work for me 😞

@yuchanns
Copy link

yuchanns commented Aug 21, 2023

For Asahi Fedora Remix users:

I faced the same issue and QT_AUTO_SCREEN_SCALE_FACTOR doesn't work for me.

But there is no problem when I use Flameshot in Asahi Arch (without any env var prefix with QT_).

Solution: So I copy the binary compiled from Asahi Arch and place it to Asahi Fedora Remix to resolve that.

TODO: I will try on installing it from Fedora Remix with pacman to see if it works.

@raygan
Copy link

raygan commented Dec 3, 2023

Same problem on Fedora 39 with Gnome/Wayland. None of the work arounds listed above work for me.

@coralof
Copy link

coralof commented Dec 11, 2023

Same issue on Fedora 39 with GNOME 45.2 on Wayland. When executing Flameshot from a keyboard shortcut or a tray icon, Flameshot issues "Cannot capture screen" error. When running via terminal (and laptop display is set at 150% scale), 'flameshot gui' produces a cropped version of the screen.

I disabled fractional scaling (set laptop display back to 100%), and the issue disappears. The only way to get it to work with a shortcut is to create a script that just runs 'flameshot gui', and then calling that script with a shortcut.

@resetko
Copy link

resetko commented Dec 13, 2023

If QT_AUTO_SCREEN_SCALE_FACTOR env works for someone, this snippet might be helpful for sway users using flameshot, it should adapt for currently active output scaling

bindsym $mod+Print exec env QT_SCREEN_SCALE_FACTORS="$(swaymsg -t get_outputs | jq 'map(select(.focused == true) | {type, focused, scale}) | .[0].scale | if . then . else 1 end | 1 / .')" flameshot gui

Worked for me on archlinux & sway

@talengu
Copy link

talengu commented Apr 2, 2024

Finally fixed by change flameshot shortcut from: flameshot gui to env QT_AUTO_SCREEN_SCALE_FACTOR=1.5 flameshot gui in which, 1.5 --->>> Settings->Display->Scale: 150%

env QT_AUTO_SCREEN_SCALE_FACTOR=1 flameshot work nice for me!!!!

image

Flameshot v12.1.0 ()
Compiled with Qt 5.11.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug It's a bug Linux Linux specific issue
Projects
None yet
Development

No branches or pull requests