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

91–100 of 264 posts

Re: Ancient X11 scaling technology

#91

Post by sho_hn »

0x457 wrote: post #89
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".

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.

It's in Wayland in the same way everything else is, i.e. fractional scaling is now a protocol included in the standard protocol suite.

> Because what is probably 90% of wayland install base only supports communicating integer scales to clients.

As someone shipping a couple of million cars per year running Wayland, the install base is a lot bigger than you think it is :)

Re: Ancient X11 scaling technology

#92

Post by enriquto »

sho_hn wrote: post #88
enriquto wrote: post #85

Earlier quoted context omitted.

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

the problem is that there's no reasonable thing to do when the height of the terminal in pixels is not an integer multiple of the height of the font in pixels. Whatever "it" does, will be wrong.

(And when it's an integer multiple, you don't need scaling at all. You just need a font of that exact size.)

Re: Ancient X11 scaling technology

#93

Post by BearOso »

jchw wrote: post #74
zozbot234 wrote: post #68

Earlier quoted context omitted.

> can't do anything about the fact that part of the window will look wrong if it overlaps two displays with different scaling It's silly that people keep complaining about this. It's a very minor effect, and one that can be solved in principle only by moving to pure vector rendering for everything. Generally speaking, a window will only ever span a single screen. It's convenient to be able to drag a window to a separ…

> It's silly that people keep complaining about this. It's a very minor effect, and one that can be solved in principle only by moving to pure vector rendering for everything. If you have DPI virtualization, a very sufficient solution already exists: pick a reasonable scale factor for the underlying buffer and use it, then resample for any outputs that don't match. This is what happens in most Wayland compositors. Ex…

I think having any kind of "scaling" preferences focuses too much on the technical aspect. It could be narrowed down to one setting like "zoom level" or just "size." This would mean that all UI elements change size exactly proportionately to one another. Ideally, rendering should happen at the exact resolution of the display, and scaling, as in resizing a bitmap using bilinear interpolation or whatever, doesn't need to be part of the pipeline except for outdated legacy programs.

In the past, the problem with UI toolkits doing proportional sizing was because they used bitmaps for UI elements. Since newer versions of Qt and Gtk 4 render programmatically, they can do it the right way. Windows mostly does this, too, even with win32 as long as you're using the newer themes. MacOS is the only one that has assets prerendered at integer factors everywhere and needs to perform framebuffer scaling to change sizes. But Apple doesn't care because they don't want you using third-party monitors anyway.

Edit: I'm not sure about Apple's new theme. Maybe this is their transition point away from fixed asset sizes.

Re: Ancient X11 scaling technology

#94

Post by sho_hn »

enriquto wrote: post #92
sho_hn wrote: post #88

Earlier quoted context omitted.

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.

the problem is that there's no reasonable thing to do when the height of the terminal in pixels is not an integer multiple of the height of the font in pixels. Whatever "it" does, will be wrong. (And when it's an integer multiple, you don't need scaling at all. You just need a font of that exact size.)

You're overthinking things a bit and are also a bit confused about how font sizes work and what "scaling" means in a windowing system context. You are thinking taking a bunch of pixels and resampling. In the context we're talking about "scaling" means telling the software what it's expected to output and giving it an opportunity to render accordingly.

The way the terminal handles the (literal) edge case you mention is no different from any other time its window size is not a multiple of the line height: It shows empty rows of pixels at the top or bottom.

Fonts are only a "exact size" if they're bitmap-based (and when you scale bitmap fonts you are indeed in for sampling difficulties). More typical is to have a font storing vectors and rasterizing glyphs to to the needed size at runtime.

Re: Ancient X11 scaling technology

#95

Post by ndiddy »

rwmj wrote: 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.

> But can I ssh to my remote server and run emacs or another program completely transparently yet with Wayland? Nope.

Yes, you can! Waypipe came out 6 years ago. Its express purpose is to make a Wayland equivalent to ssh -X. https://gitlab.freedesktop.org/mstoeckl/waypipe/

Re: Ancient X11 scaling technology

#96

Post by jeffbee »

kragen wrote: post #43

I think it was yesterday that people's on HN were saying GLX doesn't work over the network?

Are there people who believe this? What do they think Indirect GLX is? XQuartz as the server and some Linux box as the client has always worked perfectly for me, GLX included.

Re: Ancient X11 scaling technology

#97

Post by 0x457 »

arp242 wrote: post #75
nixosbestos wrote: post #22

Earlier quoted context omitted.

Good luck if you plug in an external monitor. (Not to speak of refresh rates)

I don't know about that; I use just one screen (laptop or HDMI, not both at the same time which is presumably what you're referring to) and it works for that. That's not really what the previous person was talking about either.

If you have two monitors with very different DPI, for example, I almost poke my eyes out when I tried 5k and 1440p together, you only have two choices: render for 5k and scale down to 1440p or render at 1440p and upscale to 5k. Well, you can also pick a middle ground that makes both monitors look blurry. Either way, at least one monitor will be _very_ blurry.

Re: Ancient X11 scaling technology

#98

Post by Avamander »

okanat wrote: post #38
wmf wrote: 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…

Where does Windows handle it? It's a hodgepodge of different frameworks that often look absolutely abysmal at any scale besides 100%.

Re: Ancient X11 scaling technology

#99

Post by jeffbee »

jchw wrote: post #61

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

I sort of wanted Fresco (previously Berlin, inspired by InterViews) to succeed, because in their model the UI toolkits really were server-side and they could be changed out while the application was running. Because they were targeting an abstract device (could be a 1200 dpi printer and a 72 dpi display at the same time) they got the property you mentioned, for free.

Re: Ancient X11 scaling technology

#100

Post by 0x457 »

sho_hn wrote: post #91
0x457 wrote: post #89

Earlier quoted context omitted.

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.

It's in Wayland in the same way everything else is, i.e. fractional scaling is now a protocol included in the standard protocol suite. > Because what is probably 90% of wayland install base only supports communicating integer scales to clients. As someone shipping a couple of million cars per year running Wayland, the install base is a lot bigger than you think it is :)

Hmmm, sorry, but I don't care about install base of wayland in a highly controlled environment (how many different monitor panels you ship is probably less amount of displays with different DPI in my living room right now).
Post reply on HN