Live data from Hacker News

High-DPI displays and Linux

lwn.net

101–106 of 106 posts

Re: High-DPI displays and Linux

#101

Earlier quoted context omitted.

It does work well. The other day, there was an article on someone who did an extreme test on pixel scaling, and an Apple software engineer wrote the following comment: https://news.ycombinator.com/item?id=8634895 The part of the comment that I found the most interesting was his take on a solution: 1. Make everything vectors. You'll have to choose between weird antialiasing artifacts and potential pixel cracks; either…

I'm curious about this. Aren't fonts vector files with some hinting?

I do t know about the "some", but that is what that Apple engineer says:

Which leads to the problem of centering. I wish to center a bitmap image within a button's border. The image is 101 logical points high, and the border is 200 logical points high. With a 2x scale factor, I can center absolutely, and still be aligned to device pixels. With a 1x, 1.25, 1.33, etc. scale factor, centering will align me on a partial pixel, which looks like crap. So I have to round. Which way? If the goal is "make it look good," then the answer is "whichever way looks good," which depends on the visual style of the bezel, i.e. whether the top or bottom has more visual weight. So now we need hinting.

And that's where things start to get really nasty. In order to make things look good at arbitrary resolutions, we want to round to device pixels. But the rounding direction is not a local question! Consider what happens if we have two visual elements abutting in logical coordinates, and they round in opposite directions: now there's a device pixel between them. That's very visible: you get a pixel crack! So you have to coordinate rounding.

Question: even with hinting, is it actually possible to make a font where two glyphs align perfectly without white space between them?

WPF is a good example of a framework that attempted resolution independence and encountered this problem. Initially it has the "SnapsToDevicePixels" property, which triggers rounding behavior at draw time. But draw time is too late, because of the "abutting elements rounding in opposite directions" problem. So they introduced the "UseLayoutRounding" property, which does...something. And the guidance is basically "turn it on and see if it helps, if not, disable it." Great.

I think a way out of this is way higher DPI with some blurring as the last step. That's what print does. At 1000 or 2500 DPI nobody will notice aliasing anymore, and he blurring would take care of small cracks between objects that supposedly are abutting, make cases where two objects that shouldn't accidentally do overlap less obnoxious, etc.

Re: High-DPI displays and Linux

#102
post #86
post #64

Earlier quoted context omitted.

It often is better to sell cheap stuff to many people, than to sell expensive stuff to a few. VW bought Porsche, Fiat bought Ferrari etc. :D

Actually, Porsche bought VW: http://en.wikipedia.org/wiki/Porsche_Automobil_Holding_SE

No. Porsche tried to buy VW, neatly made it but ran out of money during the financial crisis. VW took advantage and the deal reversed.

Note that Porsche SE used to own Porsche AG directly, but now VW owns it.

To quote your link:

In July 2012, it was announced that Volkswagen AG was taking over the Porsche AG automotive company completely, which bears the same name, but is only a subsidiary of Porsche SE.

Re: High-DPI displays and Linux

#103
Another interesting angle is that it’s not only application software we need to change, but also the hardware drivers are not quite there yet:

I have a Dell UP2414Q (3840x2160 resolution, driven via DisplayPort 1.2) connected to a nVidia GTX 660 card, which was one of the cheapest ones that support DP 1.2.

With the proprietary nvidia driver, I need to manually edit the xorg configuration file to have the correct modes and most importantly disable XRandR in favor of Xinerama.

This in turn breaks e.g. GNOME shell on Fedora 20 (without RandR, you’ll just get an exception in your syslog), and in general prevents plenty of use-cases (e.g. redshift for controlling display brightness, or changing rotation settings without restarting X11).

The reason for having to disable RandR is that there is not currently a standard way on how to represent multi-stream transport (MST) connections, and 4K displays require 2 streams (1920x1080 each) at the same time. With RandR enabled, what you’ll see is 2 connected outputs, and all applications will treat them as such, even though you have only one monitor connected.

Fixing this requires changes in RandR (i.e. the X server) and each driver. AFAIK, on the intel driver this should work, on nouveau there’s work under way, no clue about the proprietary nvidia driver.

Re: High-DPI displays and Linux

#104
post #103

Another interesting angle is that it’s not only application software we need to change, but also the hardware drivers are not quite there yet: I have a Dell UP2414Q (3840x2160 resolution, driven via DisplayPort 1.2) connected to a nVidia GTX 660 card, which was one of the cheapest ones that support DP 1.2. With the proprietary nvidia driver, I need to manually edit the xorg configuration file to have the correct mode…

I'm running 3840x2160 on a Samsung U28D590 with the GeForce GTX 780 6GB card over DisplayPort 1.2 with 4 lanes @ 5.4GB/s.

Driver version: 346.16 XOrg server version: 1.16.1 (11601000)

The only issue I've ran into is that Gnome Shell won't respond to clicks when I run in 30bits/pixel mode.

Re: High-DPI displays and Linux

#105

Earlier quoted context omitted.

The development you're describing is the timeline of how this stuff trickled into inexpensive consumer hardware. Expensive workstations already had big monitors and 1280x1024 resolutions in the 1980's. Also, on a related tangent: prior to 1970, computers already ran with processor clocks over 30 Mhz, with 32 bit (or larger) words, and virtual memory. These things did not show up in the Intel 80368 and start to be sup…

http://static.giantbomb.com/uploads/original/0/1792/348195-j...

Not bad catch, I remember the picture, certainly nineties.

Re: High-DPI displays and Linux

#106
post #50

OS X has the best highdpi implementation at the moment, and use the pixel scaling approach. It seems to work well there.

The extent to which the third party software ecosystem supports Retina is, I think, the greatest strength of OS X at the moment.

Probably because the pixel scaling method requires much less works by developers.
Post reply on HN