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

161–170 of 264 posts

Re: Ancient X11 scaling technology

#161

Post by kiwijamo »

kelnos wrote: post #155
kiwijamo wrote: post #147

Earlier quoted context omitted.

I used to see it all the time on X11. I'd see it on YouTube/Firefox. I'd see it on VLC. I'd see it on MPV. Any video player, playing any fast paced video you'll see X11 struggle to keep up with drawing full frames that it'd just give up and draw half of one frame and another half of another frame and call it a day. The Intel driver luckily had an xorg.conf setting I could add to make this less of an issue -- I guess…

So basically what you are saying is that they could have changed a default in a config file somewhere, 5 minutes of work, but instead they decided to spend hundreds (thousands?) of person-years building something new from scratch? And that's a good thing? Oof.

I assume there's a reason Intel didn't make that particular setting the default in their x11 drivers. While it certainly fixed the screen tearing issue, I presume there was some tradeoff which made some other feature worse off. Wayland however I assume is already built so it doesn't need the driver to implement some workaround to fix it, it's already designed to correctly handle video output by ensuring only the full frame is rendered every single frame.

Re: Ancient X11 scaling technology

#162

Post by uecker »

kllrnohj wrote: post #146
nullc wrote: post #108

Earlier quoted context omitted.

> Yes, it was slow, Not particularly if you are on a low latency network. Modern UI toolkits make applications way less responsive that classical X11 applications running across gigabit ethernet. And even on a fast network the wayland alternative of 'use RDP' is almost unusable.

the approach used in this blog post requires rdp. It's not drawing using X, so there's no vector network transparency.

Clients can draw locally and composite remotely. I do not see the issue.

Re: Ancient X11 scaling technology

#163

Post by chrismorgan »

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

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

Re: Ancient X11 scaling technology

#164

Post by roca »

zozbot234 wrote: post #73
astrange wrote: post #53

Earlier quoted context omitted.

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

> Free-scaling UIs were tried for years before that and never once got to acceptable quality. The web is a free-scaling UI, which scales "responsively" in a seamless way from feature phones with tiny pixelated displays to huge TV-sized ultra high-resolution screens. It's fine.

You are correct. I worked on this for years at Mozilla. See https://robert.ocallahan.org/2007/02/units-patch-landed_07.h... and https://robert.ocallahan.org/2014/11/relax-scaling-user-inte... for example. Some of the problems were pretty hard but the Web ended up in a pretty good place --- Web developers pretty much don't think about whether scaling factors are fractional or not, and things just work... well enough that some people don't even know the Web is "free-scaling UI"!

Re: Ancient X11 scaling technology

#165

Post by chrismorgan »

pedrocr wrote: post #56
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...

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.

It landed four years ago, but had debilitating problems. Maybe a year ago when I last tried it, it was just as bad—no movement at all. But now, it seems largely fixed, hooray! Just toggled widget.wayland.fractional-scale.enabled and restarted, and although there are issues with windows not synchronising their scale (my screen is 1.5×; at startup, one of two windows stayed 2×; on new window, windows are briefly 2×; on factor change, sometimes chrome gets stuck at the next integer, probably the same issue), it’s all workaroundable and I can live with it.

Ahhhhhhhh… so nice.

Re: Ancient X11 scaling technology

#166

Post by c-hendricks »

pwnna wrote: post #139
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…

So I don't understand where the meme of the blurry super-resolution based down sampling comes from. If that is the case, what is super-resolution antialiasing[1] then? Images when rendered at higher resolution than downsampled is usually sharper than an image rendered at the downsampled resolution. This is because it will preserve the high frequency component of the signal better. There are multiple other downsamplin…

> So I don't understand where the meme of the blurry super-resolution based down sampling comes from. If that is the case, what is super-resolution antialiasing

It removes jaggies by using lots of little blurs (averaging)

Re: Ancient X11 scaling technology

#167

Post by Ballas »

rwmj wrote: post #48
kragen wrote: post #43

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

$ 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!

Re: Ancient X11 scaling technology

#168

Post by rusk »

atq2119 wrote: post #118
astrange wrote: post #79

Earlier quoted context omitted.

That's actually a different kind of scaling. The one at issue here is closer to cmd-plus/minus on desktop browsers, or two-finger zooming on phones. It's hard to make that look good unless you only have simple flat UIs like the one on this website. They did make another attempt at it for apps with Dynamic Type though.

I'm certain that web style scaling is what the vast majority of desktop users actually want from fractional desktop scaling. Thinking that two finger zooming style scaling is the goal is probably the result of misguided design-centric thinking instead of user-centric thinking.

> misguided design-centric thinking

More like “let the device driver figure it out” - Apple is after all a hardware company first.

Re: Ancient X11 scaling technology

#169

Post by zozbot234 »

jchw wrote: post #127
BearOso wrote: post #93

Earlier quoted context omitted.

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…

Using vector pipelines isn't new, of course: Windows has been doing DPI-independent rendering since almost the beginning with GDI. The actual issue with GDI's scaling is all about text: for something to be "scalable" it has to maintain its proportions when the scale factor changes, but this was not the case for text in Win32/GDI, due to pixel grid fitting. Because of this, it was common in the Windows XP era to see i…

> Because of this, it was common in the Windows XP era to see ill-sized text when changing the DPI to anything other than 96, resulting in things being cut off and generally broken.

The underlying issue with this is the use of fixed-layout interfaces in Win32. If you tweak the layout dynamically to be "responsive" to how the text wraps, this becomes an absolute non-issue. It could also be done with reasonable efficiency at the time; early versions of KDE/Qt already did this out of the box on the same hardware as Win9x.

Post reply on HN