Live data from Hacker News

Ancient X11 scaling technology

flak.tedunangst.com

51–60 of 264 posts

Re: Ancient X11 scaling technology

#51
post #46

It's like the "oh no, X11 suffers from tearing video" problem that they pull out all the time. (A) I have no idea what "video tear" is and (B) I play video all the time on my crappy laptop running X11 and it seems fine for me. But can I ssh to my remote server and run emacs or another program completely transparently yet with Wayland? Nope. I do that with X11 continuously.

I've seen video tearing on X. Usually it doesn't happen, often it's hard to notice anyway; and when it did happen and was annoying, I just was missing some setting or other. No big deal.

Re: Ancient X11 scaling technology

#52
post #44
post #33

Earlier quoted context omitted.

It's actually a somewhat bad and uninformed post, or perhaps the mistake (unclear whether knowingly or not) is to disprove a claim made by uninformed people. No one with a good grasp of the space ever claimed that it wasn't possible on X11 to call into APIs to retrieve physical display size and map that to how many pixels to render. This has been possible for decades, and while not completely trivial is not the hard…

> to disprove a claim made by uninformed people KDE developer wrote recently: > X11 isn’t able to perform up to the standards of what people expect today with respect to .., 10 bits-per-color monitors,.. multi-monitor setups (especially with mixed DPIs or refresh rates),... [1] Multi-monitor setups are working since 20+ years. 10 bits are also supported (otherwise how would the PRO versions of graphic cards support t…

Nate (the author of the blog post you linked), who I know personally very well, is a QA/product person focused on integration and fit and finish issues. What he means to say is that as a polished product, this is now available in the form of a Wayland-based desktop session without fiddling, while the same cannot be said of X11-based ones. It's meant as a pragmatic take, not as a history lesson.

That's quite similar to how I chose to phrase is, and comes down to where the community chose to spend the effort to solve all the integration issues to make it so.

Did the community decide that after a long soul-seeking process that ended with a conclusion that things were impossible to make happen in X11, and does that paper you invoke exist? No, not really. Conversations like this certainly did take place, but I would say more in informal settings, e.g. discussions on lists and at places like the X.org conference. Plenty of "Does it make sense to that in X11 still or do we start over?" chatter in both back in the day.

If I recall right, the most serious effort was a couple of people taking a few weeks to entertain a "Could we fix this in an X12 and how much would that break?" scenario. Digging up the old fdo wiki pages on that one would for sure be interesting for the history books.

The most close analogue I can think of that most in the HN audience are familiar with is probably the Python 2->3 transition and decision to clean thing up at the expense of backward compat. To this day, you will of course find folks arguing emotionally on either side of the Python argument as well.

For the most part, the story of how this happened is a bit simpler: It used to be that the most used X11 display server was a huge monolith that did many things the kernel would not, all the way to crazy things like managing PCI bus access in user space.

This slowly changed over the years, with strengthening kernel infra like DRM, the appearance of Kernel Mode Setting, with the evolution of libraries like Mesa. Suddenly implementing a display server became a much simpler affair that mostly could call into a bunch of stuff elsewhere.

This created an opening for a new smaller project fully focused on the wire protocol and protocol semantics part, throwing away a lot of old baggage and code. Someone took the time to do that and demonstrate how it looks like, other people liked what they saw and Wayland was born.

This also means: Plenty of the useful code of the X11 era actually still exists. One of the biggest myths is that Wayland somehow started over from scratch. A lot of the aforementioned stuff that over the years migrated from the X11 server to e.g. the kernel is obviously still what makes things work now, and libraries such as libinput, xkbcommon that nearly every Wayland display server implementation uses are likewise factored out of the X11 stack.

Re: Ancient X11 scaling technology

#53
post #41
post #8

Earlier quoted context omitted.

> doing the "draw at 2x scale and then scale down" dance that was popularized by OSX Originally OS X defaulted to drawing at 2x scale without any scaling down because the hardware was designed to have the right number of pixels for 2x scale. The earliest retina MacBook Pro in 2012 for example was 2x in both width and height of the earlier non-retina MacBook Pro. Eventually I guess the cost of the hardware made this t…

> Originally OS X defaulted to drawing at 2x scale without any scaling down because the hardware was designed to have the right number of pixels for 2x scale. That's an interesting related discussion. The idea that there is a physically correct 2x scale and fractional scaling is a tradeoff is not necessarily correct. First because different users will want to place the same monitor at different distances from their e…

> But more importantly because having integer scaling be sharp and snapped to pixels and fractional scaling a tradeoff is mostly a software limitation. GUI toolkits can still place all ther UI at pixel boundaries even if you give them a target scaling of 1.785. They do need extra logic to do that and most can't.

The reason Apple started with 2x scaling is because this turned out to not be true. Free-scaling UIs were tried for years before that and never once got to acceptable quality. Not if you want to have image assets or animations involved, or if you can't fix other people's coordinate rounding bugs.

Other platforms have much lower standards for good-looking UIs, as you can tell from eg their much worse text rendering and having all of it designed by random European programmers instead of designers.

Re: Ancient X11 scaling technology

#54
It’s astounding to me that in Linux, in 2025, I can’t just simply output a custom resolution. You are probably typing a response right now with some xrandr nonsense and I PROMISE you, it won’t do it. I can’t even scale my screen within a normal resolution to make it fit within a boundary. But I can do this in windows with an nvidis gpu. Crazy

Re: Ancient X11 scaling technology

#55
post #4

That's probably better than most scaling done on Wayland today because it's doing the rendering directly at the target resolution instead of doing the "draw at 2x scale and then scale down" dance that was popularized by OSX and copied by Linux. If you do it that way you both lose performance and get blurry output. The only corner case a compositor needs to cover is when a client is straddling two outputs. And even in…

Isn't OS X graphics supposed to be based on Display Postscript/PDF technology throughout? Why does it have to render at 2x and downsample, instead of simply rendering vector-based primitives at native resolution?

No, CoreGraphics just happened to have drawing primitives similar to PDF.

Nobody wants to deal with vectors for everything. They're not performant enough (harder to GPU accelerate) and you couldn't do the skeumorphic UIs of the time with them. They have gotten more popular since, thanks to flat UIs and other platforms with free scaling.

Re: Ancient X11 scaling technology

#56
post #49
post #47

Earlier quoted context omitted.

That's what I referred to with "we'll be finally getting that in Wayland now". For many years the Wayland protocol could only communicate integer scale factors to clients. If you asked for 1.5 what the compositors did was ask all the clients to render at 2x at a suitably fake size and then scale that to the final output resolution. That's still mostly the case in what's shipping right now I believe. And even in integ…

> That's still mostly the case in what's shipping right now I believe All major compositors support fractional scaling extension these days which allows pixel perfect rendering afaik, and I believe Qt6 and GTK4 also support it. https://wayland.app/protocols/fractional-scale-v1#compositor...

Seems like the support is getting there. I just checked Firefox and it has landed the code but still has it disabled by default. Most users that set 1.5x on their session are probably still getting needless scaling but hopefully that won't last too long.

Re: Ancient X11 scaling technology

#57
Brilliant. This is another piece of evidence on the pile of why we got Wayland: it's because people who understood X11 mostly retired and everyone else couldn't be bothered to learn X11 because it's "yucky C code" or something. And it bothers me that we lose remote rendering with Wayland (unless one fights with waypipe) that was just built-in to X11. Yes, it was slow, but actually if you're running a VM on your local system and using SSH to connect to it, then it works great. Sigh. I'm an old person yelling at clouds.

Re: Ancient X11 scaling technology

#58
post #38
post #6

Drawing a circle is kind of cheating. The hard part of scaling is drawing UI elements like raster icons or 1px hairlines to look non-blurry.

And also doing it for multiple monitors with differing scales. Nobody claims X11 doesn't support different DPIs. The problems occur when you have monitors with differing pixel densities. At the moment only Windows handles that use case perfectly, not even macOS. Wayland comes second if the optional fractional scaling is implemented by the toolkit and the compositor. I am skeptical of the Linux desktop ecosystem to do…

This is exactly right.

There is no mechanism for the user to specify a per-screen text DPI in X11.

(Or maybe there secretly is, and i should wait for the author to show us?)

Re: Ancient X11 scaling technology

#59
post #47
post #42

Earlier quoted context omitted.

What you want is exactly how fractional scaling works (on Wayland) in KDE Plasma and other well-behaved Wayland software: The scale factor can be something quirky like your 1.785, and the GUI code will generally make sure that things nevertheless snap to the pixel grid to avoid blurry results, as close to the requested scaling as possible. No "extra window system transforms".

That's what I referred to with "we'll be finally getting that in Wayland now". For many years the Wayland protocol could only communicate integer scale factors to clients. If you asked for 1.5 what the compositors did was ask all the clients to render at 2x at a suitably fake size and then scale that to the final output resolution. That's still mostly the case in what's shipping right now I believe. And even in integ…

In KDE Plasma we've supported the way you like for quite some years, because Qt is a cross-platform toolkit that supported fractional on e.g. Windows already and we just went ahead and put the mechanisms in place to make use of that on Wayland.

The standardized protocols are more recent (and of course we heavily argued for them).

Regarding the way the protocol works and something having to be retrofitted, I think you are maybe a bit confused about the way the scale factor and buffer scale work on wl_output and wl_surface?

But in any case, yes, I think the happy camper days are coming for you! I also find the macOS approach attrocious, so I appreciate the sentiment.

Re: Ancient X11 scaling technology

#60

Brilliant. This is another piece of evidence on the pile of why we got Wayland: it's because people who understood X11 mostly retired and everyone else couldn't be bothered to learn X11 because it's "yucky C code" or something. And it bothers me that we lose remote rendering with Wayland (unless one fights with waypipe) that was just built-in to X11. Yes, it was slow, but actually if you're running a VM on your local…

This is nonsensical myth-making. Despite the clickbait title, the APIs called in those code samples are very basic and not some forgotten wizardry.
Post reply on HN