Ancient X11 scaling technology

Sigh. And now that it's been long enough, everyone will conveniently forget all of the reasons why this wound up being insufficient, and think that all of the desktop environment and toolkit developers are simply stupid. (Importantly, applications actually did do this by default at one point. I remember a wonky-looking nvidia-xsettings because of this.)

The thing X11 really is missing (at least most importantly) is DPI virtualization. UI scaling isn't a feature most display servers implement because most display servers don't implement the actual UI bits. The lack of DPI virtualization is a problem though, because it leaves windows on their own to figure out how to logically scale input and output coordinates. Worse, they have to do it per monitor, and can't do anything about the fact that part of the window will look wrong if it overlaps two displays with different scaling. If anything doesn't do this or does it slightly differently, it will look wrong, and the user has little recourse beyond searching for environment variables or X properties that might make it work.

Explaining all of that is harder than saying that X11 has poor display scaling support. Saying it "doesn't support UI/display scaling" is kind of a misnomer though; that's not exactly the problem.

Can this handle the case in which you have two displays with different DPIs side-by-side, and a window is placed in the middle of them both?

What part is nonsensical? Because Wayland is basically a fulfillment of jwz's CADT.

Thanks! By retrofitting I mean having to have a new protocol with this new opt-in method where some apps will be getting integer scales and go through a transform and some apps will be getting a fractional scale and rendering directly to the output resolution. If this had worked "correctly" from the start the compositors wouldn't even need to know anything about scaling. As far as they knew the scaling metadata could have been an opaque value that they passed from the user config to the clients to figure out. I assume we're stuck forever with all compositors having to understand all this instead of just punting the problem completely to clients.

When you say you supported this for quite some years was there a custom protocol in KWin to allow clients to render directly to the fractionally scaled resolution? ~4 years ago I was frustrated by this when I benchmarked a 2x slowdown from RAW file to the same number of pixels on screen when using fractional scaling and at least in sway there wasn't a way to fix it or much appetite to implement it. It's great to see it is mostly in place now and just needs to be enabled by all the stack.

> Oracle owns the rights to the NeWS source code so I'm not allowed to post it on my Github page.

They are certainly not making any money with it right now. All patents should be expired by now. Have you ever sincerely asked if you are allowed to publish the code?

> Do you have any ... display servers that solve all the problems too?

X11 has extensions which correct for most of its original flaws. Most importantly XRandr (as mentioned in the article), DRI3 (fast hardware access) and XRender (accelerated drawing primitives that don't suck). With the exception for the availability of a decent toolkit and HDR extension X11 solves all the problems.

> Or comments on any of these?

Oh boy... well, you asked for it.

> Pie Menus

Great for demos and to collect grant money, i guess. But in principle a total anti-pattern. People read from left to right and from top to bottom. Traditional context menus are therefore far superior, especially for varying numbers of options.

> Weirdly dragable tabs

Not impressed at all, sorry. Creates much more visual confusion than generic title bars.

> HyperTIES

The most revolutionary component are links... which are not invented by HyperTIES.

> PSIBER

Genuinely very impressive. A proper visual postscript debugging tool. But also necessary for a rather unintuitive stack based language like postscript which is primarily designed to be machine readable.

> SimCity

Great Game. Thanks again for making that available to the FOSS community.