A few HiDPI tricks for Linux • Hacker News Board

Re: A few HiDPI tricks for Linux

#161

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

cycloptic wrote: post #157

pedrocr wrote: post #150

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

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

That's one case where the downside is the same, not even worse, and the cases where that's not the case are broken. Wayland pushes a lot of things to the client, so it's surprising that the client can't make this decision when at worst the result has the same problem. And there are a lot of clients that could take advantage of this today. The browsers we are using to have this discussion are made needlessly blurry because of this. They have the whole stack ready for fractional scaling themselves and are forced to 2x and scale down by the compositor.

Re: A few HiDPI tricks for Linux

#162

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

pedrocr wrote: post #160

cycloptic wrote: post #159

Earlier quoted context omitted.

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

There is no "non-broken" way that an app can consistently render at a real number scale into an integer sized buffer. Everything is going to have rounding or blurring in some way. This is unavoidable.

If you follow the email I linked a while ago, this was mostly a decision in Weston, not really particularly related to GTK. But if you want to follow the conversation on where Gnome is at with this, see here: https://gitlab.gnome.org/GNOME/mutter/-/issues/478

The end comments there are what I'm getting at, the only reliable way to do this is to just bypass scaling completely and have something where the client says "never scale my buffer at all on any monitor." But of course that has the same issues with mixed DPI and you would only really want to use it for performance-sensitive applications that are not particularly sensitive to scale.

Re: A few HiDPI tricks for Linux

#163

Post by pedrocr » Sun, Jan 31, 2021, 1:01 PM UTC

cycloptic wrote: post #162

pedrocr wrote: post #160

Earlier quoted context omitted.

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

There is no "non-broken" way that an app can consistently render at a real number scale into an integer sized buffer. Everything is going to have rounding or blurring in some way. This is unavoidable. If you follow the email I linked a while ago, this was mostly a decision in Weston, not really particularly related to GTK. But if you want to follow the conversation on where Gnome is at with this, see here: https://gi…

> There is no "non-broken" way that an app can consistently render at a real number scale into an integer sized buffer. Everything is going to have rounding or blurring in some way. This is unavoidable.

This is just not true. There's nothing special about 1x and 2x when you're rendering a font or a vector. 1.5x may very well be the scale at which everything snaps into the pixel grid because that's how the pt->px conversion happened to play out at that given DPI. Thinking of 1x and 2x rendering as being special cases is exactly the problem here. And even for things where you want to pixel align if you leave that to the client some can make more intelligent decisions. There's nothing stopping a UI library snapping everything to the pixel grid at arbitrary scales by varying the spacing between elements slightly between steps. That's the whole point, the client can do better things in a lot of cases and while the discussion was about Weston the Wayland protocol has ended up with this limitation, which makes sense since Weston is the reference implementation. There's currently no way for a client to request the scale factor of the screen and render directly at that factor.

> But of course that has the same issues with mixed DPI and you would only really want to use it for performance-sensitive applications that are not particularly sensitive to scale.

There's no problem with mixed-DPI. If you have a 1x screen and a 1.5x screen render at 1.5x and scale down in the lower screen when spanning two screens. When in one screen exclusively render directly at 1x or 1.5x.

Re: A few HiDPI tricks for Linux

#164

Post by helge9210 » Sun, Jan 31, 2021, 1:20 PM UTC

Is there any desktop environment, where you can set font, interface elements sizes in points (1/72 inch) and let the system handle all the scaling?

Re: A few HiDPI tricks for Linux

#165

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

pedrocr wrote: post #163

cycloptic wrote: post #162

Earlier quoted context omitted.

There is no "non-broken" way that an app can consistently render at a real number scale into an integer sized buffer. Everything is going to have rounding or blurring in some way. This is unavoidable. If you follow the email I linked a while ago, this was mostly a decision in Weston, not really particularly related to GTK. But if you want to follow the conversation on where Gnome is at with this, see here: https://gi…

> There is no "non-broken" way that an app can consistently render at a real number scale into an integer sized buffer. Everything is going to have rounding or blurring in some way. This is unavoidable. This is just not true. There's nothing special about 1x and 2x when you're rendering a font or a vector. 1.5x may very well be the scale at which everything snaps into the pixel grid because that's how the pt->px conv…

The real serious issues are not really with fonts and vectors, it's when you have a surface within a surface. (In the context of a browser, think flash plugins, JS canvas and the like) Those have to be pixel sized, which means practically you are forced to 1x, 2x, 3x... It is unfortunately a special case that is incredibly common, and it has to be handled. Solving this by snapping everything to the pixel grid is another form of rounding that has its own set of artifacts with elements jittering around when the window gets resized, and it breaks down again if you try to have surfaces within those subsurfaces. (e.g. You decide to display a cached buffer within your flash app or JS canvas) These problems are exacerbated further when you have mixed DPI, it actually makes it much worse, and you still have one screen that is going to be scaled down and blurry.

At some point maybe I'll put together a post to illustrate this, I know it seems easy when you think about it but if you try to implement it you'll see it causes a huge number of problems. They are not unsolvable but the amount of clients that are going to care enough to solve them all is very small. (Fundamentally this cannot really be solved in a browser either for the reasons I described above)

If you want to work on this, please do it, but don't say I didn't warn you that it's a rabbit hole. I've actually done everything you're suggesting before in other projects, and honestly we've really only scratched the surface of why trying to do this kind of scaling is problematic.

Re: A few HiDPI tricks for Linux

#166

Post by sgt » Sun, Jan 31, 2021, 1:34 PM UTC

leokennis wrote: post #155

sgt wrote: post #145

Earlier quoted context omitted.

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

You have a good point with non-HiDPI screens like a 1080p screen, but I guess that's falling out of fashion anyway. With 4k screens the problem does not exist. The Windows solution is certainly an engineer's approach, but overall it's not necessarily the best when it comes to accessibility. Look at macOS accessibility settings - it's comprehensive.

Re: A few HiDPI tricks for Linux

#167

Post by vetinari » Sun, Jan 31, 2021, 2:05 PM UTC

leokennis wrote: post #133

mlindner wrote: post #89

Earlier quoted context omitted.

I'm sorry what? I've used Windows 10 scaling and it looks horrible compared to MacOS native 2x HiDPI scaling. The computers are made for HiDPI or not and it looks very natural compared to windows which doesn't scale all elements by the same amount.

I use macOS on a good old 24” 1080p monitor. It’s either “tiny text town” or “blurry shit town”.

24" 1080p is not hidpi; it is normal @1X scale.

If you have it blurry, it is because you upscale @1X.

Re: A few HiDPI tricks for Linux

#168

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

mixmastamyk wrote: post #130

microtonal wrote: post #10

Earlier quoted context omitted.

I have used a 4k screen for several years now without any issues on GNOME with 200% scaling. However, I recently bought a ThinkPad T14 with a 1080p screen. With 100% scaling, the fonts and widgets are too small. The ideal scaling seems to be 125% or 150%. GNOME has experimental support for fractional scaling. This works generally ok for Wayland applications, but windows of X11 applications are incredibly blurry both…

Get rid of the 1080, it's 2021.

14" WQHD would have the same problem, you would just switch 125% to 150%.

The ideal would be 3200x2000, but sadly, nobody sells such laptops anymore. Everyone jumps from WQHD to 4k. With 4k, you have exactly the same problem, except for 125% you need 250%.

Re: A few HiDPI tricks for Linux

#169

Post by vetinari » Sun, Jan 31, 2021, 2:15 PM UTC

gnull wrote: post #83

canofbars wrote: post #67

Earlier quoted context omitted.

>but everything has worked almost flawlessly. Its because everyone having issues is using X and likely 2 monitors with different dpis. On wayland its pretty much flawless unless you use 2 monitors at different scales and load an X application.

> unless you use 2 monitors at different scales and load an X application Agree 100%, this is the only issue I ran into using Wayland (Sway) with different DPI monitors. I only want to stress that the impact of this issue is very limited—at least for me. Most of the apps that I use run natively on Wayland and scale perfectly: Firefox (with some extra setup), Telegram Desktop, Alacritty, all GTK and KDE apps. The apps…

The sad thing is, that Google Earth is a Qt app. If they updated the Qt they ship with, it would be fine. However, Google Earth looks being abandoned.

Re: A few HiDPI tricks for Linux

#170

Post by vetinari » Sun, Jan 31, 2021, 2:16 PM UTC

yjftsjthsd-h wrote: post #99

canofbars wrote: post #68

Earlier quoted context omitted.

>It would be nice if distributions would do a better job of handling this for you They did, its called wayland. If you want to use a legacy tool you shouldn't expect it to work as nice as the current generation software.

> If you want to use a legacy tool you shouldn't expect it to work as nice as the current generation software. I'm not using the "current generation" because it doesn't work as nice as the "legacy" software. Have y'all figured out how to do screen sharing without per-compositor hacks yet?

> Have y'all figured out how to do screen sharing without per-compositor hacks yet?

Yes, it is called Pipewire.