|
|
|
|
|
by orangeboats
788 days ago
|
|
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. |
|
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.