Hacker News Reader

Comment by orangeboats | Hacker News Reader

The thing is, many things in X11 are "hardcoded" to the protocol.

For example, there is only one coordinate space in the X11 world. This meant that 1 pixel is always N "real" pixels (typically N=1).

But nowadays we have this thing called HiDPI, where 1 pixel can mean 1.5 real pixels on one screen (150% scaling), 2 real pixels on the second (200% scaling), and 1 real pixel on the third (100% scaling). We need mixed DPI and hence multiple coordinate systems, but you will break existing X11 programs if you tried to add that to the protocol, and at this point if you force your way through the problem it'll just be Wayland.

Existing X11-compatible systems "fix" this by:

1. assuming N=scale factor, thus upscaling all programs. Everything becomes a blurry mess (see XWayland).

2. assuming N=1, and let the programs upscale themselves. The problem is older apps (e.g. GTK2) don't understand HiDPI and you get a GUI for ants.

View on HN

> But nowadays we have this thing called HiDPI, where 1 pixel can mean 1.5 real pixels on one screen (150% scaling), 2 real pixels on the second (200% scaling), and 1 real pixel on the third (100% scaling).

This is the wrong way to do scaling and even Wayland got it wrong and has been very slowly fixing things. What you actually want to do is just use real pixels everywhere and just tell the client "here's your NxM window size and it will be displayed in a X scale" and let the client do the intelligent thing. If it's a browser, a 3D game, or a PDF reader it will render directly at target resolution and scale with no fuzziness and those are most use cases people care about. GUI toolkits were stuck at integer scaling for a long time and thus the strange solutions to render at higher resolution and then scale down happened. All of this can work in X11, just always use native resolution for everything but Wayland is much better anyway and works great these days.

Wouldn't that mean every application has to re-invent (or include) some form of scaling? Isn't it better than the display manager handles that for you?

The app knows how to render its UI, the display manager can only upscale or downscale what the app has provided. You get more performance and better quality if the app renders to the needed resolution in the first place, rather than if the display manager scales up or down to it.

> What you actually want to do is just use real pixels everywhere and just tell the client "here's your NxM window size and it will be displayed in a X scale"

This is already how the Wayland fractional scaling protocol works. You have a 100x60 window and Wayland tells you the scale is 1.5. You give Wayland a 150x90 framebuffer and call it a day.

The giant problem with X11 is that it is still making the assumption that everything is one giant screen -- even if you have multiple monitors and whatnot. Even the act of sending a scaling event like Wayland does is a challenge on X11.

Wayland has gotten it right in the latest protocols but up to very recently it still did only integer scaling and scaled down for fractional. Scaling the buffer in fake coordinates is also needlessly complex. Just start with the 150x90 buffer to begin with and the scaling is just a UI hint. All of that would work fine with X11 exactly because there's no need for fake coordinates. All scaling is the client's job based on a DPI or scale hint.

Reply on news.ycombinator.com