Bug#1093671: blurry images in GTK apps (eog, firefox, geeqie, etc)

[Antoine Beaupre]

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

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:

Loading Image...

that should *not* look blurry on your screen: it should look crystal
clear.

Now, look at this screenshot of geeqie rendering that above
screenshot:

Loading Image...

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

[Antoine Beaupré]

Just tested with loupe (rust, glib) and the results are similar to eog:
slight blurriness.

It's more evident when you use a highly detailed image like this:

Loading Image...

Here's the image, in fullscreen, with gwenview:

Loading Image...

And in loupe:

Loading Image...

The difference is subtle, but when you start looking at it, you can't
unsee it. Look at the stars, how they "dim" out, or the branches in the
tree on the right, normally pretty sharp, somehow dissolving in loupe.

When I load those two images in gwenview, they actually look *more*
similar than when I look at the two renderings on screen, where the
loupe render is much blurrier.

Now, this could also be issues with the renderers themselves at this
point, and not wayland. The more I look into this, the more I get lost.

One thing is sure for me now: geeqie is doing it wrong. Here's a
screenshot of geeqie rendering the same image, again:

Loading Image...

Now that is *clearly* more blurry to me.

So maybe this is more specific to geeqie than GTK in general, but I
can't shake the feeling there's something wrong across the board
here. There has been scaling issues in Geeqie in the past, so that might
be part of why it's misbehaving so badly:

https://github.com/BestImageViewer/geeqie/issues/561

[Antoine Beaupré]

For what it's worth, I have now tested gimp, and i find it renders the
image full screen *better* than gwenview. (It did take a couple of
minutes to turn off *everything* in gimp to get the right view though.)

Considering the G in GTK stands for "Gimp", this might not be a GTK
issue after all, although it's quite likely Gimp renders images
radically different than anything else out there.

a.