Package: sway Version: 1.10-2 Severity: important So this is going to sound insane, but it looks to me as all images loaded under Sway by GTK-derived image viewers are blurry.
At first, I thought this was an issue with screenshotting tools. I was redoing the screenshot for undertime, and found the newer version wasn't as sharp as the previous ones. I blamed this on fractional scaling, and figured such was life, a small price to pay compared to the misery of fractional displays in Xorg. But then I found out about this bug in shotman: https://todo.sr.ht/~whynothugo/shotman/11 ... and thought, "great, someone fixed this". But no, what the shotman maintainer said is: > 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. Then I started testing things. In my tests most of the image viewers I could get my hands on display images with a noticeable blur. This includes flagship software like Firefox and "eye of gnome", the built-in GNOME image viewer, but also geeqie, imv, pqiv and, more concerning for my amateur photography work, Darktable and possibly even Digikam. It does *not* include swaybg, qimgv, koko and gwenview, which leads me to believe this is a GTK-specific issue (although Digikam is obviously built on top of Qt/KDE, so I might be wrong, either on the GTK theory, or on my Digikam test). A simple way to reproduce this issue is to take a full screen screenshot with: shotman -c output Then display it, full screen, in the tested application. Try swapping between your different workspaces, you should see a noticeable "blur" or "fuzziness" ("aliasing"?) added around pixels. It works best if you put the full screen image viewer in a workspace next to the workspace you screenshot, the differences should be obvious. You can even screenshot the issue. Here's a screenshot of my desktop where you can see a foot window running the above `shotman` command: https://paste.anarc.at/publish/2025-01-20-Ie2Gs5QhtTBWLYdIf9XuPD-6jrIzTSvElDNmahN-Fj0/Screenshot.from.2025-01-20.at.21_52_06.280461690.png that should *not* look blurry on your screen: it should look crystal clear. Now, look at this screenshot of geeqie rendering that above screenshot: https://paste.anarc.at/publish/2025-01-20-Ie2Gs5QhtTBWLYdIf9XuPD-6jrIzTSvElDNmahN-Fj0/Screenshot.from.2025-01-20.at.22_24_02.364998203.png That *should* look blurry, regardless of where you load it, and it's how I experience it. (And yes, there's a white line on the right of the screenshot, I also see this in geeqie, before the second screenshot is made. I think it's a separate, geeqie-specific, bug.) (Fine minds will also notice the size difference between the two images: the second screenshot is more than twice as large as the first one. My bet is this is the PNG lossless compression struggling to deal with the fuzzy pixels.) This does not occur in geeqie on a "normal" GNOME desktop environment, which leads me to believe this is an interoperability issue between Sway (or wlroots?) and GTK. I'm tempted to mark this as affecting *all* of those other projects, but that would feel rather counter-productive. The reality, though, is that I no longer trust *any* image viewer (including, distressingly, Firefox and Darktable) to give me pixel-perfect displays of images. I would love to hear from other Sway users to at least confirm I am not completely losing my mind over here. I would love even more to hear something to the effect of "oh, you're doing it wrong, you should be enabling the fubar polarity on the vortex inverter" and just fix all of this, but I suspect the reality of this bug will be slightly more horrible. I haven't filed this upstream yet, as I'm afraid of the 969 issues in that I would need to wade through to avoid duplicates. Interestingly though, I did find a (closed, 7-year-old) issue in wlroots that might be related: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/210 -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.12.6-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sway depends on: ii libc6 2.40-5 ii libcairo2 1.18.2-2 ii libdrm2 2.4.123-1 ii libevdev2 1.13.3+dfsg-1 ii libgdk-pixbuf-2.0-0 2.42.12+dfsg-1+b1 ii libgl1-mesa-dri 24.2.8-1 ii libglib2.0-0t64 2.82.4-2 ii libinput10 1.26.2-1 ii libjson-c5 0.18+ds-1 ii libpango-1.0-0 1.56.0-3 ii libpangocairo-1.0-0 1.56.0-3 ii libpcre2-8-0 10.44-5 ii libpixman-1-0 0.44.0-3 ii libsystemd0 257.2-1 ii libudev1 257.2-1 ii libwayland-client0 1.23.0-1+b1 ii libwayland-cursor0 1.23.0-1+b1 ii libwayland-server0 1.23.0-1+b1 ii libwlroots-0.18 0.18.2-2 ii libxcb-icccm4 0.4.2-1 ii libxcb1 1.17.0-2+b1 ii libxkbcommon0 1.7.0-2 ii polkitd 126-1 ii swaybg 1.2.1-1 Versions of packages sway recommends: ii foot 1.20.1-1 pn sway-backgrounds <none> ii wmenu 0.1.9-2 Versions of packages sway suggests: ii swayidle 1.8.0-1 ii swaylock 1.8.0-1 ii xdg-desktop-portal-gtk 1.15.2-1 ii xdg-desktop-portal-wlr 0.7.1-2 -- no debconf information
