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

171–180 of 192 posts

Re: A few HiDPI tricks for Linux

#171

Post by vetinari »

hollerith wrote: post #109
cycloptic wrote: post #90

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. A bit of background here: https://lists.freedesktop.org/archives/wayland-devel/2013-Ma... To illustrate, I usually use a simple example: How do you render a 20px tall font at scale 1 2/3 without being blurry or…

>To illustrate, I usually use a simple example: How do you render a 20px tall font at scale 1 2/3? You replace it with a 33px tall font. This is what Gnome 3.38 actually does in my experience: on the computer on which I am writing this, I have a scale factor of 1.50 set in the Displays pane of Gnome Settings. Google Chrome and vscode show up in the output of xlsclients, which I am told means that they are talking to…

> You replace it with a 33px tall font.

You cannot. You would need 33,333333333px font; you cannot ignore the fractional pixel errors, otherwise you will get odd bugs.

Re: A few HiDPI tricks for Linux

#172

Post by seba_dos1 »

MetaDark wrote: post #87
alwaysanon wrote: post #41

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…

Wayland has a proper protocol for fractional per-output scaling: https://wayland-book.com/surfaces-in-depth/hidpi.html . While there are many reasons why I prefer Wayland over X, this is the biggest. X only allows setting a DPI per "display", but not per screen (multiple monitor setups where you can drag windows between screens use one X "display"). So you have to resort to these hacks.

The protocol you linked to only supports integer scaling.

Re: A few HiDPI tricks for Linux

#173

Post by pedrocr »

cycloptic wrote: post #165
pedrocr wrote: post #163

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

I don't get the argument that browsers are an example of how hard this is when browsers are today already completely capable of doing the right thing as clients. And so does Windows by the way. What keeps me from having a fractionally scaled desktop is Wayland. Firefox already works, and so does Chrome.

Re: A few HiDPI tricks for Linux

#174

Post by chrismorgan »

leokennis wrote: post #43
alwaysanon wrote: post #41

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…

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.

When I heard what macOS did for fractional scaling, I said “wait, they can’t actually be doing that, surely? I mean, that’s obviously a stupidly bad way of doing it!” And even if the proper solution required more work for individual apps (it’d be only a tiny bit at most), Apple’s in a better position than Microsoft to require that their developers get it right.

I’ve still not actually seen it for myself, and even having heard from multiple sources that yes, it really does work that way, I still find it hard to believe. It’s just… “here, let’s put higher-resolution displays in our laptops, but then scale things so badly that somehow it manages to be worse than a lower-resolution 1920×1080 panel would have been”. Snatching defeat from the jaws of victory.

I also find it utterly baffling.

Re: A few HiDPI tricks for Linux

#175

Post by Dylan16807 »

cycloptic wrote: post #153
Dylan16807 wrote: post #139

Earlier quoted context omitted.

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

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

Using the compositor method makes everything blurry. It's not the same trade-off.

> then don't enable scaling in the compositor.

Turning up the font size as you suggested is not at all a proper solution.

I want to pass fractional scaling on to the program whenever possible. If it can't handle it, then 2x followed by shrinking can be the fallback.

Re: A few HiDPI tricks for Linux

#176

Post by woodruffw »

leephillips wrote: post #81
woodruffw wrote: post #51

Earlier quoted context omitted.

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.

Who said that every screen’s pixel density is the same? What kind of bizarre claim would that be? DPI is a resolution. It is not the ratio between resolution and size. It already has the units of resolution: 1/length.

Sorry, I badly misread your original comment: I read it as "I saw [a reference saying that] the two were the same," not "I've seen at least two displays with the same density."

Re: A few HiDPI tricks for Linux

#177

Post by leephillips »

woodruffw wrote: post #176
leephillips wrote: post #81

Earlier quoted context omitted.

Who said that every screen’s pixel density is the same? What kind of bizarre claim would that be? DPI is a resolution. It is not the ratio between resolution and size. It already has the units of resolution: 1/length.

Sorry, I badly misread your original comment: I read it as "I saw [a reference saying that] the two were the same," not "I've seen at least two displays with the same density."

Oh, OK. No problem.

Re: A few HiDPI tricks for Linux

#178

Post by mixmastamyk »

vetinari wrote: post #168
mixmastamyk wrote: post #130

Earlier quoted context omitted.

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

I've had a 15" 4k laptop monitor for five years, and it looks fantastic at 200%. I enabled large fonts.

I'd love a squarer monitor however, they are making a comeback. My next purchase hopefully.

Re: A few HiDPI tricks for Linux

#179

Post by leokennis »

vetinari wrote: post #167
leokennis wrote: post #133

Earlier quoted context omitted.

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.

Ok please help me then.

I have a 1080p screen, and the default rendering of macOS is too small for me.

How can I get the UI to be pixel perfect and bigger without setting a lower than native resolution?

On Windows I do this by setting the scaling factor to 125%.

Re: A few HiDPI tricks for Linux

#180

Post by vetinari »

leokennis wrote: post #179
vetinari wrote: post #167

Earlier quoted context omitted.

24" 1080p is not hidpi; it is normal @1X scale. If you have it blurry, it is because you upscale @1X.

Ok please help me then. I have a 1080p screen, and the default rendering of macOS is too small for me. How can I get the UI to be pixel perfect and bigger without setting a lower than native resolution? On Windows I do this by setting the scaling factor to 125%.

When you switch resolution to lower; the operating system cannot do anything then, and whatever you see is either your GPU or your display scaler's fault.

It will be not pixel perfect; but: In the display control panel, under "Customized" group, you should have "larger text" option, as the first one. This will keep the native display resolution, and the description will says that "it will look like XY resolution".

However, I don't currently have @1X monitor available to test it; it works with @2X display, which might not be the same - it works by rendering at higher resolution, which is how @2X normally works. But worth a try.

Post reply on HN