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

181–190 of 192 posts

Re: A few HiDPI tricks for Linux

#181

Post by vetinari »

mixmastamyk wrote: post #178
vetinari wrote: post #168

Earlier quoted context omitted.

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.

> I enabled large fonts.

In Windows, large fonts is basically 125% (120 dpi, vs the base 96 dpi, double for @2X HiDPI), except it enlarges only fonts and pushes dialog controls around, but doesn't touch raster assets. It is something that was part of Windows since '90s, but in many applications, it newer worked right, because the developers never knew about the option and newer tested it (looking at most Delphi developers here).

Changing scaling to 125% (since Windows 8 and 10) changes both font sizes, grid calculations in windows controls and bitmaps; the subtle brokenness of some apps disappears, just to be replaced by another set of subtle brokeness. However, the good news is, that the chance of developers testing in this mode is higher than them testing Large fonts.

I also have 1080p 14" laptop somewhere; at 100%/dpi the display is too tiny, at 125% it is great. I also used to have 1600x900 14" laptop (T430s) - that one, at 100% was perfect (except it was an TN display, which was different downside). Prior to that, 1440x900 (T400) - that one was a bit too large.

Re: A few HiDPI tricks for Linux

#182

Post by hollerith »

vetinari wrote: post #171
hollerith wrote: post #109

Earlier quoted context omitted.

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

Yeah, well, what Gnome does is if you ask it for 150% scaling, then it actually gives you 147% scaling or 152% scaling to make the number come out even.

Re: A few HiDPI tricks for Linux

#183

Post by gurkendoktor »

robertoandred wrote: post #9
gurkendoktor wrote: post #5

Earlier quoted context omitted.

To provide some counter-anecdata, if you are in the lucky position to have screens that work at exactly 200% (4K at 24", 5K at 27"), then Ubuntu and its derivatives will Just Work out of the box. At least that was my experience around 2017-2019. Fractional scaling factors like 150% are tricky, but macOS does not properly support them either. The only app that didn't pick up my DPI settings on Linux was Spotify, but a…

macOS supports fractional scaling just fine, by rounding up and then downscaling. Sure it's not pixel-perfect to the display, but at such high ppi it's not really noticeable, and certainly much better than trying to get actual fractional resolutions working. Apple tried true resolution independence in the early 2000s and it didn't work out. 2x and 3x scaling proved to be a much better solution.

I liked Apple's approach when the iPhone 4 and MacBook Pro 2012 came out. Adding @2x bitmaps was easy enough for developers, and the transition was quick and painless.

Since then, however, Apple's UI has (regrettably) become less about pixel-perfect bitmaps and more about black typography on white roundrects, and almost all Macs run at a scaled resolution by default, which is then typically used to display web-based apps that support fractional scaling.

I really think that Windows' approach has aged much better. Kudos to Microsoft. We could have our cake and eat it too if Apple sold Macs with slightly higher-resolution displays, and also a 5K 27" display because other manufacturers can't be bothered.

Re: A few HiDPI tricks for Linux

#184

Post by badsectoracula »

cycloptic wrote: post #88
badsectoracula wrote: post #66

Earlier quoted context omitted.

> The "Wayland Way" is for the compoisitor to relay information (monitor-reported scale, etc) to the client, and have the client figure out how to scale itself correctly. FWIW this is also the "Xorg Way" (RandR provides all the necessary information), it is just that clients do not bother. Ideally the window manager would use the information provided by RandR to set up default scale levels for each monitor and then s…

What you are describing is not enough, the X server or the X compositor would still need to scale windows up/down if they don't support scaling or if you want to have fractional scaling. It's not something a old-style window manager can do -- There is just no real "Xorg way" on how to do this right now.

This is only needed if a program doesn't support scaling itself and is something that a compositor can support. In addition there is a branch by Keith Packard for having server-side window scaling that could also be used for this and work independent of any window manager (though a compositor can also be made to work with any window manager - for example there are people using a compositor with Window Maker even though WM doesn't support composition).

Re: A few HiDPI tricks for Linux

#185

Post by badsectoracula »

vetinari wrote: post #75
badsectoracula wrote: post #66

Earlier quoted context omitted.

> The "Wayland Way" is for the compoisitor to relay information (monitor-reported scale, etc) to the client, and have the client figure out how to scale itself correctly. FWIW this is also the "Xorg Way" (RandR provides all the necessary information), it is just that clients do not bother. Ideally the window manager would use the information provided by RandR to set up default scale levels for each monitor and then s…

> FWIW this is also the "Xorg Way" (RandR provides all the necessary information), it is just that clients do not bother. One of the differences is, that Wayland surfaces do have scale property. So compositor knows, when clients do not bother, and can do scaling for them. Under X11, some clients do bother, some don't, and the compositor doesn't know which are which.

Right now there isn't any protocol for doing what i described, however this information could easily be added. EWM (or something like it) needs to be extended for scaling support. Applications could do the scaling themselves as they detect their toplevel windows be moved around, but i'm not aware of any application doing that and it'd be fighting the window manager so it isn't a good idea anyway.

But the X server already provides all the necessary information and mechanism for implementing this, it is the clients that need to use it: the window managers need to implement some way to inform toplevel windows that they need to change scale (e.g. via a custom message), applications need to inform the window manager and the compositor that they support such scaling messages (e.g. via a window attribute) and compositors need to be able to scale windows that do not support this scaling (this will probably need a special window manager compositor protocol for compositors that are independent from the window manager while still allowing the window manager to handle scaling without having to also be a compositor).

Re: A few HiDPI tricks for Linux

#186

Post by mixmastamyk »

vetinari wrote: post #181
mixmastamyk wrote: post #178

Earlier quoted context omitted.

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.

> I enabled large fonts. In Windows, large fonts is basically 125% (120 dpi, vs the base 96 dpi, double for @2X HiDPI), except it enlarges only fonts and pushes dialog controls around, but doesn't touch raster assets. It is something that was part of Windows since '90s, but in many applications, it newer worked right, because the developers never knew about the option and newer tested it (looking at most Delphi devel…

Ubuntu Mate, says 192 dpi currently.

Re: A few HiDPI tricks for Linux

#187

Post by vetinari »

badsectoracula wrote: post #185
vetinari wrote: post #75

Earlier quoted context omitted.

> FWIW this is also the "Xorg Way" (RandR provides all the necessary information), it is just that clients do not bother. One of the differences is, that Wayland surfaces do have scale property. So compositor knows, when clients do not bother, and can do scaling for them. Under X11, some clients do bother, some don't, and the compositor doesn't know which are which.

Right now there isn't any protocol for doing what i described, however this information could easily be added. EWM (or something like it) needs to be extended for scaling support. Applications could do the scaling themselves as they detect their toplevel windows be moved around, but i'm not aware of any application doing that and it'd be fighting the window manager so it isn't a good idea anyway. But the X server alr…

> But the X server already provides all the necessary information and mechanism for implementing this,

X server provides that at the display level, not at the screen level. If you do that at display level, you cannot move windows between displays, the application has to destroy and recreate them (out of all applications, only emacs can do that). If you want to use then per screen, how it is done today, then screens must have identical density.

> the window managers need to implement some way to inform toplevel windows that they need to change scale (e.g. via a custom message), applications need to inform the window manager and the compositor that they support such scaling messages (e.g. via a window attribute) and compositors need to be able to scale windows that do not support this scaling (this will probably need a special window manager compositor protocol for compositors that are independent from the window manager while still allowing the window manager to handle scaling without having to also be a compositor).

Defining the protocol would be the easier part; persuading application authors to support it would be the hard part. They would ignore it for years to come. And that's for applications that are maintained or can be updated.

So when you have to make changes, you might as well as change the protocol and adjust for achieving multiple additional objectives - which is exactly what Wayland did.

Re: A few HiDPI tricks for Linux

#188

Post by vetinari »

hollerith wrote: post #182
vetinari wrote: post #171

Earlier quoted context omitted.

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

Yeah, well, what Gnome does is if you ask it for 150% scaling, then it actually gives you 147% scaling or 152% scaling to make the number come out even.

Don't know about how Gnome does that[1], but Apple certainly does that, and it allows them to limit compounding of the pixel errors to a group of 8 or 9 pixels. Each new pixel group starts without any compounded error.

[1] Last time I checked, they didn't scale entire framebuffer as Apple does it, with output scaler. It looked like they were scaling surfaces individually with GPU and then composed the scaled surfaces into framebuffer with the same dimensions as the display resolution.

Re: A few HiDPI tricks for Linux

#189

Post by vetinari »

mixmastamyk wrote: post #186
vetinari wrote: post #181

Earlier quoted context omitted.

> I enabled large fonts. In Windows, large fonts is basically 125% (120 dpi, vs the base 96 dpi, double for @2X HiDPI), except it enlarges only fonts and pushes dialog controls around, but doesn't touch raster assets. It is something that was part of Windows since '90s, but in many applications, it newer worked right, because the developers never knew about the option and newer tested it (looking at most Delphi devel…

Ubuntu Mate, says 192 dpi currently.

192 is exactly @2X scale... so it probably just means, you have 200% scale and you probably have increased the point size of system fonts.

You laptop display is higher density than 192 dpi; at 4k, that would be 23" display.

Re: A few HiDPI tricks for Linux

#190

Post by leokennis »

vetinari wrote: post #180
leokennis wrote: post #179

Earlier quoted context omitted.

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". Ho…

That “larger text” option is the same, it will scale down to a non-display native resolution (except on the default setting). But because the pixels are so small, you notice it less.

So I think we are both aware of what Windows and macOS can do.

And for me it’s clear Windows solution is superior, as it can almost arbitrarily scale the interface to fit any size pixel perfect on any screen.

Post reply on HN