Live data from Hacker News

Ancient X11 scaling technology

flak.tedunangst.com

171–180 of 264 posts

Re: Ancient X11 scaling technology

#171
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 Actually, you can’t have exactly 1.785: the scale is a fraction with denominator 120 https://wayland.app/protocols/fractional-scale-v1#wp_fractio... >. So you’ll have to settle for 1.783̅ or 1.7916̅.

Aye, the "like" was doing a lot of heavy lifting in that sentence intentionally :).

But it's HN, so I appreciate someone linking the actual business!

Re: Ancient X11 scaling technology

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

Worst was with the discussion about Wayland having extra latency on mouse pointer movements. The explanation there was that X11 used HW pointer device that got updated as soon as there was a change but that might lead to gasp occasional pointer tearing. So better add a couple ms of latency to everything in Wayland and sample the mouse pointer position once per frame.

FWIW, I do see screen tearing on my X11 multi-monitor setup. I just don't care.

Re: Ancient X11 scaling technology

#174
post #150

Earlier quoted context omitted.

>> The hard part of scaling is drawing UI elements like raster icons or 1px hairlines to look non-blurry. And doing so actually using X not OpenGL.

Toolkits don't use X to do much (if any) drawing these days. They all use something like cairo or skia or -- yes -- OpenGL to render offscreen, and then upload to X for display (or in the case of OpenGL, they can also do direct rendering).

If you use Cairo on X11 rendering automatically happens with the XRender extension. This is a rather efficient wire protocol that supports sub-pixel coordinates, transparency, gradients and more. No off-screen rendering required. (Some of the older gtk2 theme engines worked that way and allowed beautiful UIs with fast remote capabilities.)

Re: Ancient X11 scaling technology

#175
post #167
post #48

Earlier quoted context omitted.

$ ssh glxgears runs fine!

Wow, when did that happen? A couple of years ago I could not get anything OpenGL working over ssh, no matter how hard I tried. Ever since I just accepted that as fact. But I tested it now and it just works!

hasn't this always been the case? I thought one of the whole reasons for the weird design of OpenGL API was that it was a client-server sort of thing to allow for network transparency

Re: Ancient X11 scaling technology

#176
post #151

It's not "can you provide the screen DPI to a window?" people bemoan, it's "can you draw one window across two screens with differing DPIs, transparent to the application?"

You can absolutely do that on X11, but you have to do it in the client, and no one cares to do it.

if you have to do it in the client, aka the application, then it's not transparent to the application

Re: Ancient X11 scaling technology

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

> you have monitors with differing pixel densities. At the moment only Windows handles that use case perfectly

I have a mixed DPI setup and Windows falls flat (on latest Win 11), the jank when you move a application from one monitor to another as it tells the application to redraw is horrible, and even then it sometimes fails and I end up with a cut oversized application or the app crashes.

Where as on GNOME Wayland I can resize an application to cover all my monitors and it 'just works' in making them it the same physical size on all even when one monitor is 4K and the others 1440p. There's no jank, no redraw. Yes, there's sometimes artifacting from it downscaling as the app targets the highest DPI and gets downsized by the compositor, but that's okay to me.

Re: Ancient X11 scaling technology

#178
post #8
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…

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

Completely unrelated but man was Aqua beautiful

Re: Ancient X11 scaling technology

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

As someone who just uses Linux but doesn't write compositor code or really know how they work: Wayland supports fractional scaling way better than X11. At least I was unable to get X11 to do 1.5x scale at all. The advice was always "just increase font size in every app you use". Then when you're on Wayland using fractional scaling, XWayland apps look very blurry all the time while Wayland-native apps look great.

As a similar kind of user, I set Xft.dpi: 130 in .Xresources.

If I want to use multiple monitors with different dpis, then I update it on every switch via echoing the above to `xrdb -merge -`, so newly launched apps inherit the dpi of the monitor they were started on.

Dirty solution, but results are pretty nice and without any blurriness.

Re: Ancient X11 scaling technology

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

I've found the opposite, that only macOS handles that perfectly.

Windows still breaks in several situations like different size and density monitors, but it's generally good enough.

Recent Gnome on Wayland does about as well as Windows.

Post reply on HN