Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A few HiDPI tricks for Linux

blog.yossarian.net

Post reply on HN
Print view View original

141–150 of 192 posts

Re: A few HiDPI tricks for Linux

#141

Post by cycloptic »

pedrocr wrote: post #138
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…

Quite the opposite. Once you push the problem to the client a lot of them already know how to do it and by not doing two scaling steps you can make much better decisions. And you don't need coordinates as floating point at all. What you need to do is tell the app "you have a 150x150 window on which to display content at 1.33x scale, just give me back a buffer with those properties". Wayland can work at integer coordi…

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 because you explicitly want the compositor to scale your buffer and you want it to do it correctly. If you don't want that, don't bother with messing with fractional scaling.

>you have a 150x150 window on which to display content at 1.33x scale, just give me back a buffer with those properties

Again, this comes back to the issue where now you need to deal with rounding in the client. Only the simplest of browsers, image viewers, 3D renderers, PDF viewers that have no UI chrome could get away with just passing on a fractionally scaled buffer. And for those, you can do what I described above, disable fractional scaling and do your scaling in the client, you don't need any special support in the compositor. I believe in most applications you can press Ctrl-Plus and Ctrl-Minus :)

Re: A few HiDPI tricks for Linux

#142

Post by leokennis »

sgt wrote: post #126
leokennis wrote: post #43

Earlier quoted context omitted.

Yep. Windows 10 is fantastic in this regard. MacOS on the other hand sucks. Basically the recommendation is to run a lower and blurry resolution if you want bigger buttons and text... At the same time, iOS has great scaling and text sizing options, and macOS’ interface is so abstract that it should be very easy to vectorize it, enabling seamless scaling to any size wanted. Really baffling.

Have you even used macOS on a HiDPI display? I use this every day on several setups and it shines at handling this. Windows, while it can do HiDPI as well, it's basically become a turd in terms of user friendliness and experience.

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

Re: A few HiDPI tricks for Linux

#143

Post by cycloptic »

pedrocr wrote: post #137
cycloptic wrote: post #107

Earlier quoted context omitted.

The solution in that email is essentially how it works, the only difference is that the scaling factor is forced to be an integer. >By faking them out and telling them "here's a 200x200 box to do your work" and then later scaling down that box to 150x150 prevents that code from working properly. Then question I was getting at is: how do you write a renderer that does the right thing and works properly when given a bo…

It's not how it works at all for fractional scaling, which is the point. And you don't give it a 133.33 box. That's what you're in effect doing now by having the compositor scale the whole screen. You give it an actual 133px box because since you're working at native resolution apps get snapped to pixel boundaries. > It actually is much worse for the one that doesn't match, because now you have lost the ability to do…

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. The result is the same on the 1.5x display, and on the 1.1x display it's worse, because now you're re-scaling the line that is already anti-aliased, blurring it twice.

If you get a 133px box, you are cutting off pixels at the bottom.

Edit: What you are asking is possible, right now. Just leave your primary display at 1x scale, change the secondary to 11/15 scale, and then turn up the sizing in your applications. It's actually better that nothing is needed in the Wayland protocol to do that.

Re: A few HiDPI tricks for Linux

#144

Post by ChrisMLane »

WhyNotHugo wrote: post #136

Wayland has proper scaling support as a first-class thing, so you just configure it once and forget about it. This includes per-output scaling. I was actually surprised when using a 2020 Mac that macOS doesn't actually support scaling on external displays. It seems that Linux/Wayland is on the lead here.

Yes! Scaling was a nightmare for me on X11 since I have a high resolution laptop screen and then a lower resolution external monitor. I switched to Sway and scaling, switching monitors etc. was so much simpler and just worked.

Re: A few HiDPI tricks for Linux

#145

Post by sgt »

leokennis wrote: post #142
sgt wrote: post #126

Earlier quoted context omitted.

Have you even used macOS on a HiDPI display? I use this every day on several setups and it shines at handling this. Windows, while it can do HiDPI as well, it's basically become a turd in terms of user friendliness and experience.

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.

Re: A few HiDPI tricks for Linux

#146

Post by fluffything »

azinman2 wrote: post #20
libcg wrote: post #19

This article makes it seem like these steps are necessary for most Linux setups, when in reality you can do per monitor fractional scaling from a GUI as long as you're using GNOME on Wayland. No need to fiddle with per app settings, it works transparently.

Except the author is using X11 as many people will. And what this shows is how many different environments / toolkits / settings there are out there. It would be nice if distributions would do a better job of handling this for you. I’ve run into the same issues myself, and it’s kind of hard to believe that I even had to figure out these configuration dpi settings in 2021.

But distros do handle this for you. I installed Arch last year with sway and “it just works”.

Like the OP say, if you want HiDPI fractional scaling that’s a solved problem on Wayland. If you want to stick with X11, then that’s never going to work great

Re: A few HiDPI tricks for Linux

#147

Post by Sjonny »

gorgoiler wrote: post #26

Nice. If you, like me, are blind as a bat may I recommend `Xcursor.size` as well. Anyone know how to get mouse cursor comet trails in Linux?

No idea how to get a comet trail on your cursor, but I did find oneko. Maybe it can help out if you want a cat chasing your cursor: http://www.daidouji.com/oneko/

Re: A few HiDPI tricks for Linux

#148

Post by pedrocr »

cycloptic wrote: post #143
pedrocr wrote: post #137

Earlier quoted context omitted.

It's not how it works at all for fractional scaling, which is the point. And you don't give it a 133.33 box. That's what you're in effect doing now by having the compositor scale the whole screen. You give it an actual 133px box because since you're working at native resolution apps get snapped to pixel boundaries. > It actually is much worse for the one that doesn't match, because now you have lost the ability to do…

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. The result is the same on the 1.5x display, and on the 1.1x display it's worse, because now you're re-scaling the line that is already anti-aliased, blurring it twice. If you get a 133px box, you are cutting off pixels at the bottom. Edit: What you are asking is possible, right now. Just…

> 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's the point. Asking it to do 2x and then scaling by a factor it's not aware of is strictly worse than giving it all the information to make good decisions.

> If you get a 133px box, you are cutting off pixels at the bottom.

No you're not. You're just sizing the window to integer pixel sizes. Just like every X WM and Wayland compositor does. Just like sway doesn't let you do a 133.333px window in 1x it shouldn't let you do one in 1.5x. But it does, so the whole desktop is not pixel aligned, not even the start of the windows.

> Edit: What you are asking is possible, right now. Just leave your primary display at 1x scale, change the secondary to 11/15 scale, and then turn up the sizing in your applications. It's actually better that nothing is needed in the Wayland protocol to do that.

This is precisely what I do. Increase the font scale in GTK and the interface scale in Firefox. That this gives me better results than the current solution is evidence that it can be done better. Unfortunately it breaks down in mixed-DPI situations.

Re: A few HiDPI tricks for Linux

#149

Post by cycloptic »

pedrocr wrote: post #148
cycloptic wrote: post #143

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. The result is the same on the 1.5x display, and on the 1.1x display it's worse, because now you're re-scaling the line that is already anti-aliased, blurring it twice. If you get a 133px box, you are cutting off pixels at the bottom. Edit: What you are asking is possible, right now. Just…

> 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 pixel aligned after you introduce a non-integer transform in the graph. When the top point in the graph is the screen, that limits a lot what you can do there.

>You're just sizing the window to integer pixel sizes. Just like every X WM and Wayland compositor does.

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

Re: A few HiDPI tricks for Linux

#150

Post by pedrocr »

cycloptic wrote: post #141
pedrocr wrote: post #138

Earlier quoted context omitted.

Quite the opposite. Once you push the problem to the client a lot of them already know how to do it and by not doing two scaling steps you can make much better decisions. And you don't need coordinates as floating point at all. What you need to do is tell the app "you have a 150x150 window on which to display content at 1.33x scale, just give me back a buffer with those properties". Wayland can work at integer coordi…

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 fact that it works and improves things just shows how this could be done better.

> The reason you pass the buffer scale in wayland is because you explicitly want the compositor to scale your buffer and you want it to do it correctly. If you don't want that, don't bother with messing with fractional scaling.

That's circular. You're arguing that the way things are done is an argument for things to continue to be done like that.

> Only the simplest of browsers, image viewers, 3D renderers, PDF viewers that have no UI chrome could get away with just passing on a fractionally scaled buffer.

Both Firefox and Chrome have their whole UI scalable at arbitrary values and have for many years. See layout.css.devPixelsPerPx in Firefox for example. There's nothing special about the window where the Webpage/PDF/3D gets rendered versus the UI. Vector UIs that can scale arbitrarily not only exist they're widely used. And the worst case is still "if you don't know any better do 2x and scale down yourself client".

> And for those, you can do what I described above, disable fractional scaling and do your scaling in the client, you don't need any special support in the compositor. I believe in most applications you can press Ctrl-Plus and Ctrl-Minus :)

You can't disable fractional scaling on a per-program basis, it wouldn't work at all, and it would still be broken in a mixed DPI setting. I want the Browser/PDF/Image/3D windows on my 1440p screen to have different scaling from my 4K screen and for them to switch scaling automatically, just like they resize automatically, when I switch them between screens. That's currently not possible because there's no support for it in Wayland.

Post reply on HN