Skip to content

Instantly share code, notes, and snippets.

@TRPB

TRPB/wayland-scaling.md

Created January 13, 2022 21:11
Show Gist options
  • Save TRPB/a93c3ae0805a8e57b378ed65ae765fd4 to your computer and use it in GitHub Desktop.
Save TRPB/a93c3ae0805a8e57b378ed65ae765fd4 to your computer and use it in GitHub Desktop.
Download ZIP
Wayland display scaling sucks
Raw
wayland-scaling.md

Wayland's approach to scaling sucks. It's broken by design. Sorry, devs, it just does.

If I set wayland display scaling to use 1.25 scaling it scales up to 2 then back down to 1.25. This makes everything apart from fonts (which are handled differently) blurry and has a bunch of annoying side effects.

  1. Anything running in XWayland is scaled horridly and looks super blurry.

  2. Any borders of UI elements or thin lines suddenly become blurry because 2 pixels can't go into 1 pixel so the scaling algorithm blurs the the nearest two to the average colour between them.

  3. I can't view an entire 3840x2160 image in a web browser without scaling it down.

  4. XWayland applications (e.g. most games) cannot see the monitor's native resolution. A game running in XWayland can only run at the scaled resoltuon. E.g. if you have scaling set to 2x on a 3840x2160 monitor the maximum the game can render at is 1920x1080.

What's annoying is that Xorg's approach works perfectly: Scale the font using a specified DPI, then scale the UI elements around it. Sure, the odd border may look slightly thinnner than it did but it's at least snapped to the nearest pixel.

The frustrating thing about this, is that the Xorg approach breaks in one specific circumstance: When a user has two or more monitors of different sizes and/or resolutions. So to accomodate this (relatively small) audience, they have imposed the issues above on anyone who owns a high DPI display (e.g. most people who have a laptop these days, even though they don't have a second monitor so won't ever encounter the issue the scaling method is trying to fix)

There's an obvious solution to all this The whole thing is Nigel Tufnel's "These go to eleven". Instead of scaling anything:

  1. Let the user specify the font DPI for their primary monitor and scale all UI elements around that (exactly the same way Xorg scaling works at the moment). That then becomes "100%"

  2. Users who have mismatched monitors can apply scaling on their secondary display only.

That way, the only users affected by the numerous scaling issues wayland causes are the small minority of users who have multiple, mismatched displays. And the issues only ever appear on their secondary display. They can even still play games at their monitors native resolution on their primary monitor. Everyone else (the vast majority of people having a single monitor, or multiple matched displays) will never encounter any scaling issues at all!

Workaround

Luckily, this mess can (somewhat) be worked around by scaling applications. This doesn't work on KDE, unfortunately, but depending on your window manager/desktop envrionment you may be able to:

  1. Keep the desktop at the native resolution

  2. Scale applications by DPI

For GTK applications run the command gsettings set org.gnome.desktop.interface text-scaling-factor 1.25 to set your scale factor. Even on Wayland, UI elements are correctly scaled around the font DPI!

For Qt applications use the following environment variable QT_WAYLAND_FORCE_DPI=120 where 96 is the base DPI (96*1.25=120)

This works for now, but really Wayland devs need to sort out the root problem.

Rant over.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment