A few HiDPI tricks for Linux • Hacker News Board

Re: A few HiDPI tricks for Linux

#151

Post by pedrocr » Sun, Jan 31, 2021, 11:59 AM UTC

cycloptic wrote: post #149

pedrocr wrote: post #148

Earlier quoted context omitted.

> You can't be pixel perfect in the 1.5x screen if your renderer is scaling correctly and thus is rendering lines at 1.5 pixels wide. Pixel-perfect is not the standard. If you're rendering a PDF everything starts out in vector space and there's nothing special about 1x and 2x. It may very well be that 1.5x is the scale at which the PDF line becomes pixel aligned. You just don't know. But the app might know, and that'…

With the PDF you would see the same results using a filtered scaler. There is unfortunately no way to do this that doesn't break down in mixed-DPI situations because of the rounding issues. If you want to add this to a wayland implementation, I won't (and can't) stop you, but I think it's a bad idea. Just my experience from trying to write various scaled interfaces, it becomes impossible to ensure that anything is pi…

> There is unfortunately no way to do this that doesn't break down in mixed-DPI situations because of the rounding issues.

I don't think I've been able to explain then. There's strictly less rounding than today this way, Because from the point of view of Wayland every window is at native resolution and it's up to the client to scale.

> To be clear, this is if you configured your output scaling to be 2/3. 133px is absolutely not correct there.

I don't understand what you're saying. 133px is correct, just like 134px is correct. The way WMs and compositors work is they split the screen between windows at integer coordinates. That's how it works at 1x and there's no reason to not work like that at 1.5x. They're completely independent issues.

Re: A few HiDPI tricks for Linux

#152

Post by vetinari » Sun, Jan 31, 2021, 12:01 PM UTC

Too wrote: post #121

vetinari wrote: post #61

Earlier quoted context omitted.

The point is, you don't have to figure out configuration dpi settings in 2021, if you use distributions as they are supposed to be used . If you insist on your favorite x11 window manager, the integration is on you. No point in complaining then, it is self-inflicted pain.

> distributions as they are supposed to be used. As much as i like the concept of Wayland, until it's a one click always works without any caveats option in Ubuntu it essentially doesn't exist. Ubuntu 20.04, the latest of the most popular distributions, does not have wayland enabled by default. They actively discourages you from trying it if you have Nvidia, which again is the most popular gfx card - not sure if one…

Ubuntu was criticized for that; every time they release LTS without default Wayland session, they delay the solution for another 2 years.

One of the reason why Apple is able to move fast, that they do not fart around with introducing new and deprecating old things; if you are not ready for that, it is your problem, stick with old release. So most vendors get ready for the new things, because they know there's no way to avoid them. In Linux land, we have people putting hacks on top of other hacks just to avoid switching to the new thing, and in this case, the existing Ubuntu LTS releases are part of the problem.

Also, Nvidia is not the most popular GPU in general. It is a gamer card. Most used GPU is Intel. Intel has some 70% share; the rest is split between Nvidia and AMD.

Re: A few HiDPI tricks for Linux

#153

Post by cycloptic » Sun, Jan 31, 2021, 12:07 PM UTC

Dylan16807 wrote: post #139

cycloptic wrote: post #124

Earlier quoted context omitted.

You do have to propagate the scaling factor, but as long as it's an integer scale, you don't have to convert all your coordinates to use floating-point everywhere and enforce rounding rules. I'd also like to point out that if you are rounding in your rendering anywhere, you are now likely either introducing blurriness again, or something is getting scaled incorrectly. The only real way I know to do this without causi…

> I'd also like to point out that if you are rounding in your rendering anywhere, you are now likely either introducing blurriness again, or something is getting scaled incorrectly. Some things will be blurry, but no worse than having the compositor do it. Other things will not be blurry, and that's a huge huge benefit. > artifacts or error build-up Integer multiples risk artifacts too, if the program is actually sup…

>Some things will be blurry, but no worse than having the compositor do it. Other things will not be blurry, and that's a huge huge benefit.

This is the same trade-off as you would get without it.

The precision isn't an issue, the error build-up is with rounding and it becomes particularly problematic when you have subsurfaces.

As I have said in another sibling comment, if you don't want the compositor to do any scaling, then don't enable scaling in the compositor.

Re: A few HiDPI tricks for Linux

#154

Post by cycloptic » Sun, Jan 31, 2021, 12:09 PM UTC

pedrocr wrote: post #151

cycloptic wrote: post #149

Earlier quoted context omitted.

With the PDF you would see the same results using a filtered scaler. There is unfortunately no way to do this that doesn't break down in mixed-DPI situations because of the rounding issues. If you want to add this to a wayland implementation, I won't (and can't) stop you, but I think it's a bad idea. Just my experience from trying to write various scaled interfaces, it becomes impossible to ensure that anything is pi…

> There is unfortunately no way to do this that doesn't break down in mixed-DPI situations because of the rounding issues. I don't think I've been able to explain then. There's strictly less rounding than today this way, Because from the point of view of Wayland every window is at native resolution and it's up to the client to scale. > To be clear, this is if you configured your output scaling to be 2/3. 133px is abs…

It's not correct because you are not rendering at 2/3 scale anymore, you are rendering at 0.665 or 0.67 scale. What you are describing is rounding, you can't do this without rounding. Worse, with that method the scale technically changes every time you resize the window. This is hard to explain in text on HN and I don't have reference images to illustrate this at the moment, sorry.

Re: A few HiDPI tricks for Linux

#155

Post by leokennis » Sun, Jan 31, 2021, 12:10 PM UTC

sgt wrote: post #145

leokennis wrote: post #142

Earlier quoted context omitted.

I’m not talking about HiDPI. I’m talking about people who like all UI elements and text a little bigger.

Option key while choosing the "size" desired in Screen settings. Gives you more options and there's a solution for everyone. I think my resolution is 2640x something on my 4k. Crisp and large enough, although some would find it too small.

I’m not saying it’s a lack of resolutions to choose from.

Let’s say a default button is 100px wide with 10pt font size and I have a 1920x1080 screen.

If I choose “125%” on Windows, it will render the button 125px side with 12.5pt font. With the caveat that I can render fewer buttons on my screen.

On macOS I just need to pick a lower resolution, and then after al UI elements are rendered, scale it up to 1920x1080. This results in a scaled up and thus not pixel perfect and thus blurry picture.

So Windows renders bigger UI elements at native resolution. macOS always renders a button 100px wide, you can just pick a lower resolution on a high res screen so those 100px seem bigger.

Re: A few HiDPI tricks for Linux

#156

Post by vetinari » Sun, Jan 31, 2021, 12:18 PM UTC

rfoo wrote: post #129

vetinari wrote: post #72

Earlier quoted context omitted.

I've got 4K display for my Linux machine in 2017; Fedora+Gnome+Wayland worked fine at 200% scale back then. That's 4 years. After those 4 years, there are people still trying to make their X11 square peg fit into the HiDPI round hole. X11 is dead. Nobody is going to retrofit HiDPI into it as it is in Wayland. In another 4 years, it is still going to be as annoying as it is today to fix up X11 desktops and apps; maybe…

> worked fine at 200% scale My X11 setup also works perfectly fine back then, at 200%. Maybe even earlier, 2016 or so. The caveat is, of course, 200%. Try 150% and it is really a pain in the ass.

> Try 150% and it is really a pain in the ass.

Yes and no.

Wayland clients work file with 150%, or 125%, or whatever scaling. X11 client don't, they are blurry, as they are upscaled from @1X scale.

In the past, I considered that a problem, but I no longer do. You see, 20 years ago, one of the great things Apple did with their migration to Unix-like system was to make X11 clients second class citizens, beyond any doubt. You had to run X11 server manually and later, they even stopped shipping XQuartz with the system. It was a message, that while X11 apps work, if you are the author, you should really make your apps native.

Blurriness of X clients is a similar message here. You want it sharp? Ask its author for a native client. By dragging the feet the problem won't be solved. Chrome, and by extension Electron, are "working" on Wayland support since, what, 2016? For 5 years? They obviously do not see any need for it. The blurriness is a kick so they feel that they should see the need.

Similarly, JetBrains. Recently, there was an article how they partnered with Azul to rework their JIT for M1. M1 is a product, that wasn't on the market yet, but they were working on supporting it. On the other hand, they haven't managed to introduce Wayland support during last years yet. Again, the difference is, that they know M1 is inevitable, but they can afford to delay with Wayland, the users will excuse that, will look for hacks on their own and they won't be blamed anyway.

So if anything, the problem is too nice Xwayland integration and Ubuntu, that delayed switch to default Wayland session, giving time to ISVs to ignore the Wayland support for another couple of years. The distributions have to signal inevitable changes; the problems that will appear by not doing so will be their own, and solving them later will be harder.

Re: A few HiDPI tricks for Linux

#157

Post by cycloptic » Sun, Jan 31, 2021, 12:20 PM UTC

pedrocr wrote: post #150

cycloptic wrote: post #141

Earlier quoted context omitted.

They aren't forced to draw at 2x and be scaled down. They only need to do that if you have enabled fractional scaling. If you really want to avoid the overdraw associated with that, just don't use any scaling on your primary display and then turn the font size in your client up. Anything else that passes the fractional scale onto the client is going to have issues. The reason you pass the buffer scale in wayland is b…

> They aren't forced to draw at 2x and be scaled down. They only need to do that if you have enabled fractional scaling. Fractional scaling is exactly what we're talking about. At 1x/2x everything works. > If you really want to avoid the overdraw associated with that, just don't use any scaling on your primary display and then turn the font size in your client up. That's what I do but doesn't work with mixed-DPI. The…

>Fractional scaling is exactly what we're talking about. ... That's circular. You're arguing that the way things are done is an argument for things to continue to be done like that.

Actually no, what you are describing is ideally having no scaling at all in the compositor on any particular monitor. (Unless of course a window is stretched between them) I'm not arguing for things to be done any way, I'm saying don't misuse a feature that was designed to do something else than what you're asking for.

For a vector UI that is supposed to be pixel-aligned, you can't render that at a non-integer scale without the same blurriness that you would get with doing the scaling in the compositor. That's different from rendering print content that has no relation to pixels.

Re: A few HiDPI tricks for Linux

#158

Post by pedrocr » Sun, Jan 31, 2021, 12:21 PM UTC

cycloptic wrote: post #154

pedrocr wrote: post #151

Earlier quoted context omitted.

> There is unfortunately no way to do this that doesn't break down in mixed-DPI situations because of the rounding issues. I don't think I've been able to explain then. There's strictly less rounding than today this way, Because from the point of view of Wayland every window is at native resolution and it's up to the client to scale. > To be clear, this is if you configured your output scaling to be 2/3. 133px is abs…

It's not correct because you are not rendering at 2/3 scale anymore, you are rendering at 0.665 or 0.67 scale. What you are describing is rounding, you can't do this without rounding. Worse, with that method the scale technically changes every time you resize the window. This is hard to explain in text on HN and I don't have reference images to illustrate this at the moment, sorry.

> It's not correct because you are not rendering at 2/3 scale anymore, you are rendering at 0.665 or 0.67 scale.

You won't get the same result as rendering the entire screen at the same scale because you're snapping windows to integer borders. But that's the whole point. The app however is scaling at 2/3 within that window box and that's actually what you want because it gives better results. There's nothing special about scaling the whole screen that you can't do by scaling each individual window after first snapping all windows to integer sizes.

Re: A few HiDPI tricks for Linux

#159

Post by cycloptic » Sun, Jan 31, 2021, 12:25 PM UTC

pedrocr wrote: post #158

cycloptic wrote: post #154

Earlier quoted context omitted.

It's not correct because you are not rendering at 2/3 scale anymore, you are rendering at 0.665 or 0.67 scale. What you are describing is rounding, you can't do this without rounding. Worse, with that method the scale technically changes every time you resize the window. This is hard to explain in text on HN and I don't have reference images to illustrate this at the moment, sorry.

> It's not correct because you are not rendering at 2/3 scale anymore, you are rendering at 0.665 or 0.67 scale. You won't get the same result as rendering the entire screen at the same scale because you're snapping windows to integer borders. But that's the whole point. The app however is scaling at 2/3 within that window box and that's actually what you want because it gives better results. There's nothing special…

If the app is still rendering into that box at 2/3 scale, then it is either cutting off pixels at the bottom or you will get a seam at the bottom.

Re: A few HiDPI tricks for Linux

#160

Post by pedrocr » Sun, Jan 31, 2021, 12:41 PM UTC

cycloptic wrote: post #159

pedrocr wrote: post #158

Earlier quoted context omitted.

> It's not correct because you are not rendering at 2/3 scale anymore, you are rendering at 0.665 or 0.67 scale. You won't get the same result as rendering the entire screen at the same scale because you're snapping windows to integer borders. But that's the whole point. The app however is scaling at 2/3 within that window box and that's actually what you want because it gives better results. There's nothing special…

If the app is still rendering into that box at 2/3 scale, then it is either cutting off pixels at the bottom or you will get a seam at the bottom.

Only if the app is broken. The rendering engine needs to be able to fill whatever pixel size at whatever scale. If you mean that you can no longer do 2x and scale down at the exact perfect scale then that's true, but only a limitation of that way of rendering. It's also broken for whole screen scaling, just less noticeable. Firefox and Chrome don't have that issue at all for example, and neither does anything that renders fonts and vectors. At a guess this is probably where all this came from. GTK decided integer scaling was all it was going to support and then everything else was decided as if all clients behaved like that. I doubt even that's a problem. The differences in scale from doing 2x and scale down per-app instead of per-screen are miniscule.