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

241–250 of 264 posts

Re: Ancient X11 scaling technology

#241

Post by account42 »

lelandbatey wrote: post #16

I admire your tenacity. I think folks say "X11 doesn't support DPI scaling" when they should say "most programs written against X11 to use official Xlib functionality don't understand scaling". In the article, the author uses OpenGL to make sure that they're interacting with the screen at a "lower level" than plenty of apps that were written against X. But that's the rub, I think the author neatly sidestepped by most…

Are you running xeyes and simmilar examples? Because real programs and their toolkits have being doing their own rendering (using OpenGL or software rasterizers) for ages.

Re: Ancient X11 scaling technology

#242

Post by uecker »

kllrnohj wrote: post #195
uecker wrote: post #162

Earlier quoted context omitted.

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

draw locally composite remotely is literally Wayland's philosophy and is one of the biggest contentious issues for the pro-X11 crowd.

This what Wayland copied from modern X clients.

Re: Ancient X11 scaling technology

#243

Post by em-bee »

yjftsjthsd-h wrote: post #212
em-bee wrote: post #176

Earlier quoted context omitted.

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

If we can require applications to draw their own window controls, I think we can ask them to handle their pixel densities.

that's a good point. window controls should be at the proper scale too.

Re: Ancient X11 scaling technology

#244

Post by kccqzy »

cycomanic wrote: post #156
sho_hn wrote: post #135

Earlier quoted context omitted.

I see where you are coming from and it makes sense. I will also say though that in the most common cases where people request mixed scale factor support from us (laptop vs. docked screen, screen vs. TV) there are also other form factor differences such as viewing distance that doesn't make folks want to match DPI, and "I want things bigger/smaller there" is difficult to respond to with "calculate what that means to y…

> I see where you are coming from and it makes sense. I actually agree (even though I did not express that in my original post) that DPI is probably not a good "user visible" metric. However, I find that the scaling factor relative to some arbitrary value is inferior in every way. Maybe it comes the fact that we did not have proper fractional scaling support earlier, but we are now in the non-sensical situation that…

I find that explaining all of the above considerations to the user in a UI is hard. It's better to just let the user pick from several points on a slider for them to see for themselves.

Re: Ancient X11 scaling technology

#245

Post by kccqzy »

account42 wrote: post #220
roca wrote: post #164

Earlier quoted context omitted.

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

It mostly works but you can still run into issues when you e.g. want to have an element size match the border of another. Things like that that used to work don't anymore due to the tricks needed to make fractional scaling work well enough for other uses.

Why wouldn't it work? The border-size accepts the same kind of length units as height or width, no?

Re: Ancient X11 scaling technology

#246

Post by nextaccountic »

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

What is the status of fractional pixels in GTK? Will GTK5 finally get what KDE/Qt has today?

I recall the issue is that GTK bakes deep down the fact that pixel scaling is done in integers, while in Qt they are in floats

Re: Ancient X11 scaling technology

#247

Post by jchw »

account42 wrote: post #237
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…

Applications (or rather UI toolkits) need to handle scaling no matter what if you want a crisp result without giant intermediate renders. Figuring out the scale is the easy part as the article shows. > Worse, they have to do it per monitor, and can't do anything about the fact that part of the window will look wrong if it overlaps two displays with different scaling. That is not a real issue. Certainly not anything w…

That's fine. It doesn't need to be absolutely perfect, it just needs to be good enough. What isn't good enough is if you can't even use legacy apps because they're too small. What is good enough is if DPI aware apps can have crisp rendering and DPI-unaware apps can render at the correct size on screen but blurry. Totally fine, it's exactly what Windows and macOS (and not X11) do.

You can fix this with extensions... Kind of, anyway. It's really not that trivial. Like if you do DPI virtualization, you need it to take effect across literally everything. Like for example, some applications in X11 will read xrandr information for window placement. To properly handle DPI-unaware applications, you need to be able to present virtualized coordinates to some applications. This is actually one of the easier problems to solve, it goes downhill from there.

Re: Ancient X11 scaling technology

#248

Post by lotharcable »

kelnos wrote: post #150
phkahler wrote: post #13

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

Yes toolkit authors have realized they have to avoid X11 as much as possible if they want to have good results.

This one of the major motivations as to why X11 guys decided Wayland was a good idea.

Because having your display server draw your application's output instead of your application drawing the output is a bad idea.

Re: Ancient X11 scaling technology

#249

Post by lotharcable »

dontlaugh wrote: post #180
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…

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.

Windows is the only platform that tries to do it "correctly" as per the internet peanut gallery.

And, of course, doing it "wrongly" as per what OS X and Gnome does works a lot better in practice.

Re: Ancient X11 scaling technology

#250

Post by lotharcable »

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…

It is using OpenGL to draw instead of using X11.

Which pretty much means that it is using the same code paths and drivers that get used in Wayland.

Post reply on HN