Live data from Hacker News

A few HiDPI tricks for Linux

blog.yossarian.net

111–120 of 192 posts

Re: A few HiDPI tricks for Linux

#112
post #94

Earlier quoted context omitted.

Huh? I have a 4k TV I've been using connected to my gaming computer for awhile running windows 10. I've had no end of issues with various programs becoming horribly confused by display scaling. Some applications ignore the display scaling entirely and end up tiny, and other applications (particularly some games) end up with 4x size on UI elements - which looks utterly awful. Its pretty clear lots of game developers n…

If you restrict yourself to Google Chrome, Chromium-based Edge, apps using Electron and apps recently written by Microsoft (Settings, Timer, image viewer, video player, etc), then display scaling is very slick on Windows 10. (I didn't try with multiple monitors, but I did use the Settings app to change the scaling factor frequently.) On OSX in contrast, if you change the display resolution in System Preferences, most…

OSX scaling is implemented such that non-int scaling makes pixel-perfect rendering literally impossible. (Hello moire!)

Windows has pretty perfect handing for non-int scaling, though it's on apps to do the right thing. Modern browsers (including Firefox) handle this great, though other apps may or may not.

Re: A few HiDPI tricks for Linux

#113
post #96

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.

My MacBook powering my 4K monitor doesn’t look blurry at all, and I have it set to “2560x1440” scaling in the display settings. It does however run a tiny bit slower due to that non-integer retina scaling.

It does look surprisingly good, but it's still blurring unless they changed it this year. Alternating-color pixel grids always moire there.

Re: A few HiDPI tricks for Linux

#114

My experience with 4k has essentially been that it's too small for the display sizes I want to have on my desk - and the fractional scaling support is always quite a bit of work to get right (as evidenced by this post). I've found that 2k (2560x) displays at 27" give me great real estate without any need to scale.

1440p at 27" with no scaling is perfect for my desktop. I wish it were more popular, because it's a great compromise between quality and performance for gaming.

The relatively common use of "2k" to mean 2560x1440 has always struck me as confusing though, since it's not half as wide as 4k. Words mean whatever people agree they mean, but I feel like "2k" is too ambiguous.

Re: A few HiDPI tricks for Linux

#115

Earlier quoted context omitted.

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.

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.

That hasn’t been the case for me with Ubuntu or raspbian.

Re: A few HiDPI tricks for Linux

#116
post #85

Credit where credit is due this is the one area where Windows is the best OS these days. It not only will do fractional scaling but it will do display independent fractional scaling - whack in the scaling percentage on each screen and in the recent versions of Windows 10 it works well and looks great and remembers your settings when you plug that monitor back in. It is perhaps THE thing along with WSL2 (now giving me…

Your positive experiences with this, do not mirror mine. I have one 4K main display at 200% scaling, and an old 19" off-screen I use for IRC and music playback at 100% scale. Every time I wake my machine, the windows from the off-screen are shuffled around to the main screen, and windows on the main screen are resized and moved around. It absolutely drives me up the wall, and it's clear that this configuration has ne…

Don't worry that bug isn't caused by scaling.

Re: A few HiDPI tricks for Linux

#117
post #17

I am using Retina display on which everything looks tiny. I struggled with setting up QT scaling, GTK3.0 scaling, icon sizes, font DPI and resolutions. The problem is there is no single setting which all UI libraries follow and this makes your life hell. Even worse is when you connect an external monitor which is not HiDPI and now everything is bigger than usual. Instead scale the whole display and this works perfect…

What if you want to display a pixel-perfect image? Perhaps this a rare use case, but it's important for some things, like dithering. Is there any way for you display an image where every pixel matches up to a display pixel?

Plenty of art is made assuming crisp lines too.

Re: A few HiDPI tricks for Linux

#118
post #93

Earlier quoted context omitted.

> This was discussed at length years ago and it was decided that passing a fractional scale value to the client is not what you want, makes the code much more complicated and doesn't really solve the blurriness. From your link: """ > While rendering at rational factor can't be of better quality, it can > however be done at a much higher quality than downscaling, faster and with > less memory usage. Perhaps, but that…

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…

You already have to propagate code all over to handle integer multiples, don't you?

The email seems to be worried about things happening at the wayland level with fractions, but that's easily solved by rounding entire windows to the nearest pixel.

Re: A few HiDPI tricks for Linux

#119

Earlier quoted context omitted.

If DPI means “dots per inch”, then how can the size of the screen come into it? And what is “not true”?

As the phrase "dots per inch" implies, it's a ratio. Specifically, it's the ratio between your resolution (say, 4K) and the size of your screen. What is "not true" is that every screen's pixel density is the same. Different screens have different sizes and resolutions, which means they have different pixel densities.

You need to go reread the comment you called not true.

Re: A few HiDPI tricks for Linux

#120

Earlier quoted context omitted.

This also works well on GNOME Wayland (and probably other Wayland compositors) since about 1.5 years ago (for me at least). In the display settings you can pick a scale per monitor and almost all apps will respect it. (It seems some apps with custom toolkits are lagging but I can't remember the last time I ran into one of these).

Electron is the biggest offender these days. I saw that they added support a few months ago but it seems the apps haven't turned it on yet

The good thing about Electron apps is they all usually accept ctrl+shift+plus to quickly zoom in the whole application, not just the text. Just like zooming any page in the browser.

The bad thing is it applies to all windows of that app, so you can't mix big and small vscode if put one window on laptop HD screen and one window on 4k external monitor.

Post reply on HN