fractional-scale-v1 has been merged into wayland-protocols and swaywm already has support on master.
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(_), }
Some WIP code in the
fractional-scalebranch
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
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.
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.
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.
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.pngIf 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.
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!)
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:
here's the same image, but rendered by geeqie, screenshotted again by shotman:
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.pngthe 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.
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.
i filed this as a bug against sway in debian, see https://bugs.debian.org/1093671
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.
Double checked the source for imv, and I see no references to it supporting fractional scale. Opened https://todo.sr.ht/~exec64/imv/70
IIRC, GTK3 only supports integer scaling, so all image GTK3-based image viewers are likely to render blurry when using fractional scale.
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...
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.
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
