~whynothugo/shotman#11: 
Fractional scaling support

fractional-scale-v1 has been merged into wayland-protocols and swaywm already has support on master.

Status
REPORTED
Submitter
~whynothugo
Assigned to
No-one
Submitted
1 year, 11 months ago
Updated
18 days ago
Labels
todo

~whynothugo 1 year, 11 months ago*

I think it might make sense to use an enum to store the current scale:

enum Scale {
    Unknown,
    // A value guessed by inspecting outputs and cross-referencing with `wl_surface::enter` events.
    Guessed(i32),
     // A value informed by the compositor via `wl_surface.preferred_buffer_scale`.
    Explicit(_),
    // The sent scale is the numerator of a fraction with a denominator of 120.
    Fractional(_), 
}

~whynothugo 1 year, 10 months ago

Some WIP code in the fractional-scale branch

~anarcat 20 days ago

what's the status on that branch?

i have found that basically no wayland screenshot tool properly captures pixel-perfect screenshots, at least under sway, which was surprising when coming from X11 because scaled displays are otherwise perfectly supported in Sway...

so i had high hopes when i saw that bug report, so i'm wondering what's up...

you can see a screenshot taken with grim in the undertime readme, i tested with shotman and the results are similar. this is with a 2x or 1.5x scaling, results are similarly blurry. it seems this was introduced in my x11 to sway switch here:

https://gitlab.com/anarcat/undertime/-/commit/b1b3d0474d4a07305a7c2adc7dd278454acc0e67

~whynothugo 20 days ago

shotman requests a copy of the screen into a buffer the same size as reported by the compositor. IIRC, the png compression that I'm doing is lossless, so it should save exactly what the compositor is offering.

I'd have to double check all the facts to be sure, but if the image is lower resolution that what's displayed on-screen, it might be a compositor bug.

Tracking fractional scale (i.e.: what's discussed in this issue) is only relevant for drawing the thumbnail window itself.

Antoine Beaupré 20 days ago · edit

On 2025-01-20 18:23:12, ~whynothugo wrote:

shotman requests a copy of the screen into a buffer the same size as reported by the compositor. IIRC, the png compression that I'm doing is lossless, so it should save exactly what the compositor is offering.

I'd have to double check all the facts to be sure, but if the image is lower resolution that what's displayed on-screen, it might be a compositor bug.

Oh. Then this could very well be a sway bug then, siiiigh.

~whynothugo 20 days ago

At a screen resolution of 3440x1440, the screenshot is 3440x1440, so the compositor is giving us an image in the right format. Doesn't look like a compositor issue.

~whynothugo 20 days ago

We're not doing any lossy compression on the image either. I tried opening a screenshot with mpv, and the quality is substantially better than my usual image viewer (imv)

 mpv --loop=inf Screenshot.from.2025-01-20.at.23_16_13.873859976.png

If I put my face less than 3cm away from the screen, I still notice a very minimal loss in quality. At this point, I'm not sure if the loss in quality is when saving the image or the program that's rendering it.

~anarcat 20 days ago

holy moly. you have now officially, fully, and completely blown my mind. i see the same thing: mpv renders things pixel-perfect, and (almost) all other image viewers i have tried (eog, geeqie, imv, pqiv so far) are fuzzy.

swaybg, on the other hand, is not fuzzy. qimgv is not fuzzy, but its interface is so weird that i can't actually figure out how to show the image in full screen. i'm similarly failing to display the screenshot in full size in swayimg, which is behaving similarly weirdly.

koko and gwenview seems to behave properly. so i'm tempted to lay the blame on GTK, as both of those are KDE/Qt apps, while all the weird ones are GTK (I think?)

an easy way to reproduce the issue is to take a screenshot with shotman -c output, then open it, full screen, in any image viewer. because you should be looking at almost exactly the same image, you will see the fuzziness added.

even digikam and darktable, disturbingly, doesn't seem to be able to display those pixels sharply, and those are supposed to be top-notch photography editors.

wtf. what are we supposed to do with this? all those viewers are screwed?

i am certainly reconsidering my image viewer choices at this point, ugh. i guess i should see if that happens in GNOME as well.

what a nightmare!

(thanks for tolerating my ranting here, clearly this is not your fault!)

~anarcat 20 days ago

interestingly, i can catch the bug with a shotman screenshot! here's a normal shotman screenshot of itself (more or less), this shouldn't look fuzzy:

https://paste.anarc.at/publish/2025-01-20-Ie2Gs5QhtTBWLYdIf9XuPD-6jrIzTSvElDNmahN-Fj0/Screenshot.from.2025-01-20.at.21_52_06.280461690.png

here's the same image, but rendered by geeqie, screenshotted again by shotman:

https://paste.anarc.at/publish/2025-01-20-Ie2Gs5QhtTBWLYdIf9XuPD-6jrIzTSvElDNmahN-Fj0/Screenshot.from.2025-01-20.at.22_24_02.364998203.png

bonus points if notice the sizes of the images:

https://paste.anarc.at/publish/2025-01-20-Ie2Gs5QhtTBWLYdIf9XuPD-6jrIzTSvElDNmahN-Fj0/

-rw-rw-r-- 1 anarcat anarcat 428,162 2025-01-20 21:52 Screenshot.from.2025-01-20.at.21_52_06.280461690.png
-rw-rw-r-- 1 anarcat anarcat 934,878 2025-01-20 22:24 /home/anarcat/snaps/Screenshot.from.2025-01-20.at.22_24_02.364998203.png

the screenshot of the screenshot, probably because of the aliasing/blurriness, makes the PNG compression struggle more, and the image is more than double the size!

amazing.

~anarcat 20 days ago

so for what it's worth, i can't reproduce in GNOME/Wayland... and by "can't reproduce", the images don't look blurry in geeqie in GNOME, they just look fine. i can't take a screenshot in GNOME with shotman, obviously, because we can't have nice things, although shotman could be a little more polite about it... ;)

anarcat@angela:~> shotman -c output --verbose info              (main)
thread 'main' panicked at src/main.rs:167:6:
called `Result::unwrap()` on an `Err` value: the requested global was not found in the registry
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
anarcat@angela:~[101]> RUST_BACKTRACE=1 shotman -c output --verbose info
thread 'main' panicked at src/main.rs:167:6:
called `Result::unwrap()` on an `Err` value: the requested global was not found in the registry

Stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: __libc_start_call_main
             at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
   7: __libc_start_main_impl
             at ./csu/../csu/libc-start.c:360:3
   8: <unknown>
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

i guess that's an entirely different (and probably unfixable) issue, of course...

but still, it goes to show there might be some interop issue between GTK and sway here, in particular... i guess i'll need to report this on sway now.

thanks again for the help.

~anarcat 20 days ago

i filed this as a bug against sway in debian, see https://bugs.debian.org/1093671

~whynothugo 19 days ago

This is new to me too; it didn't occur to me that image viewers might render images so poorly.

Someone on #sway on IRC mentioned that imv doesn't support fractional scale. So any image that you open will be blurry.

~whynothugo 19 days ago

Double checked the source for imv, and I see no references to it supporting fractional scale. Opened https://todo.sr.ht/~exec64/imv/70

~whynothugo 19 days ago

IIRC, GTK3 only supports integer scaling, so all image GTK3-based image viewers are likely to render blurry when using fractional scale.

~anarcat 19 days ago

Oh Oh, that's promising. I'll try to reproduce in GNOME with fractional scaling enabled, we'll see. It's difficult because from what I remember, I can't actually set a 1.5x fractional scaling, only round numbers, so that might be harder to reproduce...

~anarcat 19 days ago

i can't confirm the issue in gnome, but i can't select the same scaling (1.5) as in sway, of course on 1x and 2x this is not an issue.

~whynothugo 18 days ago

The arch wiki indicates that GNOME support fractional scaling, but it needs to be configured via gsettings, not via the UI: https://wiki.archlinux.org/title/HiDPI#Fractional_scaling

Register here or Log in to comment, or comment via email.