Scale-based bug - the screenshot is zoomed into the top left corner when using scaling != 100%

[mapleroyal]

Related to #273

This is in a relatively vanilla brand new arch install (I say relatively because I have configured it lightly and I have setup a few gnome extensions) when using 3840*2400 resolution at 200% scale.

Screenshot: https://i.imgur.com/AbUb1op.png

[dynobo]

Hi @mapleroyal , I definitely strive for supporting different scalings with NormCap, so thanks for reporting this issue!

To be able to fix it, I'd need some more information to reproduce the issue:

1. Desktop Environment (Gnome? KDE? Xfce?)
2. Display Server (XOrg? Wayland?)
3. NormCap installation method (AppImage? FlatPak? Pip? AUR?)

That would help me a lot!

[louiscklaw]

I face similar issue than mapleroyal

Q: Desktop Environment (Gnome? KDE? Xfce?)
A: Gnome 44.3

Q: Display Server (XOrg? Wayland?)
A: Wayland

Q: NormCap installation method (AppImage? FlatPak? Pip? AUR?)
A: just follow the install instructions from README.md and i am using fedora.

$ sudo dnf install tesseract wl-clipboard
$ pip install normcap
$ ./normcap

Here i am using 3840x2160 display with scall 200%.

Thanks for help in advance.

[dynobo]

Hi @louiscklaw, I'm having trouble to reproduce this, despite having the same setup like you, just Arch instead of Fedora.

Could you please run NormCap with it's debug flag, and share the output here?

./normcap -v debug

[dynobo]

Today I was able to reproduce this is issue in a VM. To me, it seems like it is related to the "Fractional scaling" (125%, 150%,...) mode, which some distros seem to have enabled by default, other haven't. So far, I was only testing with Fractional Scaling mode, and that's what NormCap currently seem to support. The "Normal" scaling mode (200%, 300%) seems to behave totally different, even if the scaling value is the same:

The way a 200% scaling is received by a Qt application on e.g. a 1920x1080 display:

• "Normal" Scaling: QScreen.size is 1920x1080, QScreen.DevicePixelRatio is 2
• Fractional Scaling enabled: QScreen.size is 960x540, QScreen.DevicePixelRatio is 2

I'll try to come up with a solution that works for both displays.

In the meanwhile, could someone with this issue please confirm my hypothesis? That would help me a lot!

1. What does gsettings get org.gnome.mutter experimental-features output for you?
2. If you enable fractional scaling via gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']", does this fix the issue with NormCap?
   (You can easily revert the fractional scaling setting afterwards by running gsettings set org.gnome.mutter experimental-features "<Whatever output you had in 1.)>")

[travisfw]

running gsettings get org.gnome.mutter experimental-features returns @as []

After enabling fractional scaling as suggested, gsettings get now returns ['scale-monitor-framebuffer']

But NormCap still zooms to the upper left corner of the screenshot and I can't discover any way to access the right edge of the window.

Edit: after reboot, NormCap now sizes to the screen so that I can select anything on the screen. But the scaling for the rest of the OS is messed up. My cursor is huge, for instance. So I can't keep it this way.

I am on Fedora Linux 38 (Workstation Edition).
Display server: Wayland
install method: Flatpak

[mapleroyal]

Hey, sorry I haven’t been able to contribute to this, I no longer have that machine. I’m pretty confident that I was using normcap installed by appimage; I just checked back at my system configuration notes and they show normcap as being installed via appimage.

[dynobo]

Thanks for testing, @travisfw ! Yeah, fractional scaling behaves different in other ways, too, so NormCap should work with both. But your confirmation, that NormCap is scaling correctly with fractional scaling activated, confirms my hypothesis that this is the root cause, so I might be able to provide a fix.

For everyone one interested, some additional background:

In the Wayland philosophy, the compositor has full control over the size and position of the application's windows. Wayland supports displaying windows in full-screen mode, but only for the screen they are currently on. There is no easy way to cover all monitors full screen. (With OpenGL this would be easily doable, but other things would get much harder, especially for a cross-platform application like NormCap).

NormCap, at least as it is currently implemented, requires full-screen coverage of all available screens. For Wayland, this is implemented with a "hacky" workaround: NormCap tries to read dimensions and positions of all screens, creates a (non-full-screen) window for each screen, resizes it to the screen's dimension, and moves it to the screen's position. This mimics multi-display fullscreens, so to speak. Since Wayland ultimately has full control over window positions and sizes, there is no guarantee that this will work on all setups and in future versions, but so far it has worked quite well.

Now, when screen scaling comes into play (which can even be set differently for each screen), this becomes even more difficult: window sizes and positions must be adjusted to match the scaling. NormCap does this by reading the scaling and dimension information of each screen via QTs API (the UI Framework, NormCap builds upon). What is new to me is that this information provided by QT seems to be different when fractional scaling is enabled or not, even when it is not used: The same setup, with the same displays and the same scaling factors (e.g. 200%) results in different scaling information from QT when fractional scaling is enabled or not.

The current NormCap issue should be fixable, e.g. by trying to guess if fractional scaling is enabled or not and considering this when resizing / repositioning the windows. It might not be super easy, and makes the hacky workaround even more hacky, but I'll give it a try.

For reference:

Other QT-based applications with similar requirements as NormCap are also struggling with those issues under Wayland. E.g. I'm following:

• ksnip ZOOMS IN on top left corner of widows display when trying to snip on WINDOWS ksnip/ksnip#941
• Fails when fractional scaling <> 100% flameshot-org/flameshot#564

[mapleroyal]

Also, the error for me would have been on GNOME on vanilla arch, using Wayland, on a “high res” laptop.

[dynobo]

A potential fix for the scaling issues is ready for testing in v0.5.0-beta1.
Would be great if you could try it, and report back if it helped! 🙂

[travisfw]

The scaling seems okay now! But the selected area seems to be off by the same scale. I just selected a blank area of the screen, and it extracted text from a smaller area up and to the left.

[dynobo]

thanks for the feedback, @travisfw !
Some more questions:

1. Do you have fractional scaling enabled? Like do you see 125%, 150% etc. in the settings? (Even if you don't use it and only have eg 200% configured it makes a difference.
2. Do you have 1 or more displays/monitors? If so: same experience on both?

[dynobo]

This problem should be fixed with the latest release. Could you please confirm?

[dynobo]

Closing for now, please feel free to re-open or create a new issue, if the issue persists.