Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ancient X11 scaling technology

flak.tedunangst.com

Post reply on HN
Print view View original

81–90 of 264 posts

Re: Ancient X11 scaling technology

#81

Post by sho_hn »

cycomanic wrote: post #71
zokier wrote: post #49

Earlier quoted context omitted.

> 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...

That's great, however why do we use a "scale factor" in the first place? We had a perfectly fitting metric in DPI, why can't I set the desired DPI for every monitor, but instead need to calculate some arbitrary scale factor? I'm generally a strong wayland proponent and believe it's a big step forward over X in many ways, but some decisions just make me scratch my head.

The end-user UIs don't ask you to calculate anything. Typically they have a slider from 100% to, say, 400% and let you set this to something like 145%.

This may take some getting used to if you're familiar with DPI and already know the value you like, but for non-technical users it's more approachable. Not everyone knows DPI or how many dots they want to their inches.

That the 145% is 1.45 under the hood is really an implementation detail.

Re: Ancient X11 scaling technology

#82

Post by okanat »

akdor1154 wrote: post #58
okanat wrote: post #38

Earlier quoted context omitted.

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?)

Natively in X11? No. Even with Xrandr. It is no. But you can obtain the display size and then draw things differently using OpenGL but now you're reinventing the display protocol in your drawing engine (which is what GLX is after all but I digress). You need to onboard every toolkit to your protocol.

Re: Ancient X11 scaling technology

#83

Post by sho_hn »

pedrocr wrote: post #67
sho_hn wrote: post #59

Earlier quoted context omitted.

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…

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…

Oh, ok. Yeah, this I agree with, and I think plenty of people do - having integer-only scaling in the core protocol at the start was definitely a regretable oversight and is a wart on things.

> 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?

Qt had a bunch of different mechanisms for how you could tell it to use a fractional scale factor, from setting an env var to doing it inside a "platform plugin" each Qt process loads at runtime (Plasma provides one), etc. We also had a custom-protocol-based mechanism (zwp_scaler_dev iirc) that basically had a set_scale with a 'fixed' instead of an 'int'. Ultimately this was all pretty Qt-specific though in practice. To get adoption outside of just our stack a standard was of course needed, I guess what we can claim though is that we were always pretty firm we wanted proper fractional and to put in the work.

Re: Ancient X11 scaling technology

#84

Post by zokier »

cycomanic wrote: post #71
zokier wrote: post #49

Earlier quoted context omitted.

> 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...

That's great, however why do we use a "scale factor" in the first place? We had a perfectly fitting metric in DPI, why can't I set the desired DPI for every monitor, but instead need to calculate some arbitrary scale factor? I'm generally a strong wayland proponent and believe it's a big step forward over X in many ways, but some decisions just make me scratch my head.

DPI (or PPI) is an absolute measurement. Scale factor is intentionally relative. Different circumstances will want to have different scale factor : dpi ratios; most software do not care if certain UI element is exactly x mm in size, but instead just care that their UI element scale matches the rest of the system.

Basically scale factor neatly encapsulates things like viewing distance, user eyesight, dexterity, and preference, different input device accuracy, and many others. It is easier to have human say how big/small they want things to be than have gazillion flags for individual attributes and then some complicated heuristics to deduce the scale.

Re: Ancient X11 scaling technology

#85

Post by enriquto »

sho_hn wrote: post #42
pedrocr wrote: post #41

Earlier quoted context omitted.

> 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…

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".

> 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

This is horrifying! It implies that, for some scaling factors, the lines of text of your terminal will be of different height.

Not that the alternative (pretend that characters can be placed at arbitrary sub-pixel positions) is any less horrifying. This would make all the lines in your terminal of the same height, alright, but then the same character at different lines would look different.

The bitter truth is that fractional scaling is impossible. You cannot simply scale images without blurring them. Think about an alternating pattern of white and black rows of pixels. If you try to scale it to a non-integer factor the result will be either blurry or aliased.

The good news is that fractional scaling is unnecessary. You can just use fonts of any size you want. Moreover, nowadays pixels are so small that you can simply use large bitmap fonts and they'll look sharp, clean and beautiful.

Re: Ancient X11 scaling technology

#86

Post by okanat »

axus wrote: post #62
okanat wrote: post #38

Earlier quoted context omitted.

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…

Speaking of X11 and Windows, any recommended Windows Xservers to add to this StackOverflow post? https://stackoverflow.com/questions/61110603/how-to-set-up-w... I hadn't heard of WSLg, vcxsrv was the best I could do for free.

With WSLg, Windows runs a native Wayland server under Windows and it will use Xwayland to display X11 apps. You should be able to use any GUI app without any extra setup. You should double check the environment variables though. Sometimes .bashrc etc. or WSL's systemd support interferes with them.

Re: Ancient X11 scaling technology

#87

Post by [deleted] »

ndiddy wrote: post #31
pedrocr wrote: 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…

Wayland has supported X11 style fractional scaling since 2022: https://wayland.app/protocols/fractional-scale-v1 . Both Qt and GTK support fractional scaling on Wayland.

[deleted]

Re: Ancient X11 scaling technology

#88

Post by sho_hn »

enriquto wrote: post #85
sho_hn wrote: 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".

> 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 This is horrifying! It implies that, for some scaling factors, the lines of text of your terminal will be of different height. Not that the alternative (pretend that characters can be placed at arbitrary sub-pixel positions) is any less horrifyin…

The way it works for your terminal emulator example is that it figures out what makes sense to do for a value of 1.785, e.g. rasterizing text appropriately and making sure that line heights and baselines are at sensible consistent values.

Re: Ancient X11 scaling technology

#89

Post by 0x457 »

sho_hn wrote: post #42
pedrocr wrote: post #41

Earlier quoted context omitted.

> 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…

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".

Is it actually in Wayland or is it "implementation should handle it somehow" like most of wayland? Because what is probably 90% of wayland install base only supports communicating integer scales to clients.
Post reply on HN