Edmundson: High DPI Progress [LWN.net]

At his blog, David Edmundson writes about the state of high-DPI support in KDE. "For some applications supporting high DPI has been easy. It is a single one line in KWrite, and suddenly all icons look spot on with no regressions. For applications such as Dolphin which do a lot more graphical tasks, this has not been so trivial. There are a lot of images involved, and a lot of complicated code around caching these which conflicts with the high resolution support without some further work." He is personally tracking the progress of many applications, but notes that there are many unsolved issues. "There are still many applications without a frameworks release even in the upcoming 15.04 applications release. Even in the next applications release in 15.08 August we are still unlikely to see a released PIM stack. Is it a good idea to add an option into our UIs that improves some applications at the cost of consistency? It's not an easy answer." This update is Edmunsdon's second post on the subject; the first, from November 2014, is also quite informative.

to post comments

Edmundson: High DPI Progress

Posted Mar 6, 2015 22:52 UTC (Fri) by luto (subscriber, #39314) [Link] (9 responses)

AFAICS Gnome has multiple conflicting settings but manages to support fractional scale factors like this:

org.gnome.desktop.interface text-scaling-factor 1.3
org.gnome.desktop.interface scaling-factor uint32 1

Can KDE do that?

I have a monitor on which 1x is rather tiny but 2x is way too big.

Edmundson: High DPI Progress

Posted Mar 7, 2015 10:00 UTC (Sat) by roc (subscriber, #30627) [Link] (6 responses)

text-scaling-factor isn't intended to scale the whole user-interface.

Requiring the scale factor to be an integer is simply a GNOME bug.

Edmundson: High DPI Progress

Posted Mar 12, 2015 10:17 UTC (Thu) by hadess (subscriber, #24252) [Link] (5 responses)

> Requiring the scale factor to be an integer is simply a GNOME bug.

It's not, it's a technical design decision:
https://blogs.gnome.org/alexl/2013/06/28/hidpi-support-in...

Edmundson: High DPI Progress

Posted Mar 12, 2015 18:34 UTC (Thu) by luto (subscriber, #39314) [Link] (4 responses)

It could well be a reasonable decision, and my current fractional text scaling setup works well.

The real issue for me is that configuring this requires voodoo magic. As far as I can tell, none of this has a real GUI, and even gnome-tweak-tool gives only partial control.

Also, getting Qt and GNOME to agree enough so that Qt apps look good on correctly configured GNOME would be nice, too.

Edmundson: High DPI Progress

Posted Mar 15, 2015 10:43 UTC (Sun) by msorvig (guest, #91585) [Link] (1 responses)

That commit looks familiar..

Support for fractional scale factors in Qt is actually not that bad, QPainDevice::metric is the only API I'm aware of where we need to work around 'int' values. We can't guarantee glitch free graphics at non-integer scale factors, so fractional scale factors will not be supported in that sense.

The current code that reads QT_DEVICE_PIXEL_RATIO enforces integer scale factors. If I had to make a decision I would probably land on giving the choice to the user and remove that limitation.

Edmundson: High DPI Progress

Posted Mar 15, 2015 22:57 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

"QPainDevice::metric" - I love it!

Edmundson: High DPI Progress

Posted Mar 15, 2015 10:54 UTC (Sun) by msorvig (guest, #91585) [Link]

This should really be configured at the windowing system level. Wayland has wl_output::scale which will be read by Qt (5.5) and used to enable high-dpi mode.

Qt could possibly read the org.gnome.desktop settings, but would that be a good idea?

Edmundson: High DPI Progress

Posted Mar 16, 2015 12:00 UTC (Mon) by hadess (subscriber, #24252) [Link]

> It could well be a reasonable decision, and my current fractional text scaling setup works well.

GNOME supports fractional text scaling just fine. Just not fractional widget scaling.

Edmundson: High DPI Progress

Posted Mar 7, 2015 10:45 UTC (Sat) by jospoortvliet (guest, #33164) [Link]

Right now, only integers work in Qt, as fractional scaling caused issues. A patch is in the work that will perhaps get merged if it works properly - but it's currently in the state 'abandoned', not sure if there is a plan B or they couldn't make it work and gave up. https://codereview.qt-project.org/#/c/86574/ for reference.

Edmundson: High DPI Progress

Posted Mar 7, 2015 15:25 UTC (Sat) by sebas (guest, #51660) [Link]

The Plasma user interfaces support fractional scaling since 5.0 (last summer's release) for the overall UI and for icons. Other assets, such as SVGs used in the UI are being worked on right now, so is loading of larger pixmaps in high-dpi settings.

I have a machine like that, too (180dpi laptop), under Plasma 5 it's enough to set the font to my liking and the rest of the UI will scale. There'll be more controls in the near future (David's blog is about that).

Edmundson: High DPI Progress

Posted Mar 7, 2015 11:51 UTC (Sat) by rsidd (subscriber, #2582) [Link] (30 responses)

This has been an issue for 10 years if not longer -- if you have a 1920x1200 15" monitor, it does not mean you want smaller icons and tinier text than if you have a 1024x768 17" monitor. (And "icon themes" with varying sizes, too, partly alleviated the problem, but it was an ugly fix.) I guess it's a hard problem to solve but everyone assumed tiny icons are OK until high-DPI came in and "tiny" became "ridiculously tiny".

On a side note, just what is the point of devices like the new Samsung Galaxy phones that have upwards of 500dpi? Anything more than 300 cannot be resolved by the best human eye. Meanwhile, higher resolution means slower processing and shorter battery life. Are customers really dumb enough to pay extra money for invisible gains and measurable losses in this DPI game? It's a bit like the audiophile scene and especially the current hd-audio nonsense -- but those have always been niche products and never made a dent on the mass market.

Edmundson: High DPI Progress

Posted Mar 7, 2015 13:12 UTC (Sat) by tialaramex (subscriber, #21167) [Link] (7 responses)

"Anything more than 300 cannot be resolved by the best human eye"

That's a marketing pitch. It's not a fact, any more than the Apple iPhone 5 was the absolute perfect size with all phones that were any bigger or smaller being "unergonomic"... Apple pays somebody to come up with "research" that proves their products are perfect, it's a normal way to do business for a large company because increasingly the modern news media doesn't really have any separation between advertising and editorial, so you can just pay them to write a "news" item about how your products have been discovered to be scientifically perfect.

Because the human visual system uses a moving "camera" with sophisticated fully adjustable optics, stochastic anti-moire sensor array and various other neat tricks it actually notices resolution improvements above 300dpi and it's hard to put a precise figure on where the upper limit it. Not to mention outside of Apple TV adverts humans don't keep their phone at a manufacturer specified distance from their face during use.

Edmundson: High DPI Progress

Posted Mar 7, 2015 13:56 UTC (Sat) by rsidd (subscriber, #2582) [Link] (6 responses)

References, please.

Edmundson: High DPI Progress

Posted Mar 7, 2015 14:13 UTC (Sat) by edeloget (subscriber, #88392) [Link] (4 responses)

From my past in digital photography (developping a photo film scanner for the professional market) I would say that 300 dpi is the absolute minimum resolution for graphics to look natural. Under that resolution, you see the pixels.

Edmundson: High DPI Progress

Posted Mar 7, 2015 15:39 UTC (Sat) by rsidd (subscriber, #2582) [Link] (3 responses)

Printing and scanning are a different story. 300 is a minimum, yes, because it's just beyond the limit of what the eye can make out. For other reasons in printing (mainly the CMYK process and "bleeding" higher is desirable in printing. For mobile phones, 300 is the maximum of what you need, and 500% is absurd. It may be true (as per another reply above) that some artifacts are visible to some people watching movies at 300dpi. But non-dpi-related artifacts are much more significant with today's codecs and playback. And in any case only professionals should care about that, not the mass market.

Edmundson: High DPI Progress

Posted Mar 7, 2015 15:40 UTC (Sat) by rsidd (subscriber, #2582) [Link] (1 responses)

I meant 500, not 500%, above, and also omitted a closing bracket. (Typed it on a mobile phone, if that's relevant!)

Edmundson: High DPI Progress

Posted Mar 7, 2015 16:13 UTC (Sat) by gevaerts (subscriber, #21521) [Link]

If your phone had a higher resolution display, you'd probably have spotted the typos!

Edmundson: High DPI Progress

Posted Mar 11, 2015 23:49 UTC (Wed) by nix (subscriber, #2304) [Link]

Typesetters have long considered 600dpi a barely-tolerable absolute minimum, 1200dpi preferable, and anything up to 9600dpi (!) a nice-to-have. I can verify that even I, with dysfunctional vision and an astigmatic world 20% smaller than most other people's due to extreme myopia, can see significant differences in font shapes (particularly stems) between 600dpi and 1200dpi.

The human eye is definitely capable of resolving detail *way* above this mythical 300dpi "limit". Even *my* eye.

Edmundson: High DPI Progress

Posted Mar 9, 2015 16:33 UTC (Mon) by jbolden1517 (guest, #100141) [Link]

There are tons of discussions of this. Perfect vision (i.e. a human infant) gives about 952 PPI as the limit. For most adults there is a pretty sharp falloff after about 600 PPI. We know from experience humans are easily able to distinguish 480 PPI displays from 640 PPI displays. 300 is nowhere near the limit.

http://www.cultofmac.com/173702/why-retina-isnt-enough-fe...
http://www.pcmag.com/article2/0,2817,2364871,00.asp

Edmundson: High DPI Progress

Posted Mar 7, 2015 16:26 UTC (Sat) by Jonno (guest, #49613) [Link] (2 responses)

> Anything more than 300 cannot be resolved by the best human eye

That is just plain wrong! In fact, ppi (pixels per inch) isn't even relevant at all when speaking of the acuity of the human eye, what you should care about is ppd (pixels per degree of arc).

Normal eye acuity [1] (aka. 20/20 vision, 6/6 vision, or 1.0 vision) is defined as being able to distinguish between two lines at an angular distance of 1 arc minute, which equates to 60 ppd.

There is however a fairly large variation in humans, various medical studies of "young adults" (presumably university students) finds *average* vision anywhere between 1.25 and 1.66 vision, and perfect human vision is quoted as anywhere between 2.5 and 4.0 depending on who you ask. That said, the best measured human eye acuity I have found in a peer-reviewed study was 2.25, which would mean that anything less than 135 ppd would look pixelated to "the best human eye".

To translate from ppd to ppi you also has to take viewing distance in consideration. Normal eye accommodation [2] allows a human to focus on objects down to 70 mm from the eye, and while typical viewing distance for phones etc is usually quoted as either 300 mm (1 foot), it too varies quite a lot among humans, down to a minimal of 70 mm.

So while a "normal" human eye at "typical" viewing distance only needs about 292 ppi for a phone to look good, *the best* human eye at *minimum* viewing distance needs about 2815 ppi before further improvements becomes pointless.

Now, myself I have just below 1.1 vision and typically use my phone at 150-200 mm, so for me the limit would be about 640 ppi, so a 500 ppi phone would still look pixelated, even if it was not quite as noticeable as on the more common 300 ppi display.

And BTW, the figures I've quoted above assumes that absolutely everything is perfectly aligned to the pixel grid! As no one has invented a perfect universal anti-aliasing algorithm yet we'll likely need to double the pixel rate, for the same reason (the Nyquist-theorem) digital audio uses twice the sample rate compared to the highest frequency the best human ear can hear...

> It's a bit like the audiophile scene and especially the current hd-audio nonsense

The equivalent to the above-"48 000 Hz" hd-audio nonsense would be above-"6 000 ppi" hd-video, and we have a *long* way to go before we get there...

[1] https://en.wikipedia.org/wiki/Visual_acuity
[2] https://en.wikipedia.org/wiki/Accommodation_%28eye%29

Edmundson: High DPI Progress

Posted Mar 7, 2015 16:44 UTC (Sat) by rsidd (subscriber, #2582) [Link] (1 responses)

So while a "normal" human eye at "typical" viewing distance only needs about 292 ppi for a phone to look good, *the best* human eye at *minimum* viewing distance needs about 2815 ppi before further improvements becomes pointless.

True but irrelevant! We're talking about mass-market devices here. But yes, my claim about "best human eye" was hyperbole too. And even if one possesses a superior-grade eye, I can imagine the ppd mattering for a professional graphics workstation but not for a mobile phone.

Edmundson: High DPI Progress

Posted Mar 7, 2015 19:43 UTC (Sat) by Jonno (guest, #49613) [Link]

> We're talking about mass-market devices here.
Exactly! For a mass market device it is not good enough to target the 50% of the population with below average visual acuity, you have to target most of the other half as well. While you can probably ignore the top 5 or 10 percentile, that still means you have people with somewhere between 1.8 and 2.0 vision in your target audience, and about half of those will want to operate the device at a below average viewing distance...

> And even if one possesses a superior-grade eye
Remember that half of the world population has above-average vision (to one degree or another), including almost every young adult, who makes up the primary market for these kind of devices...

> I can imagine the ppd mattering for a professional graphics workstation but not for a mobile phone.

Well, imho it matters *more* on a phone than for graphics editing, as phones are very space constrained and thus makes much heavier use of small details. On a workstation having to scale the graphics you are working on is not much of a deal, but on a phone that isn't really available, the closest you get is holding the device closer to your eye, at which point you will need even higher relative pixel density (ppi) to meet the angular pixel density (ppd) requirement of the eye in question.

Additionally, note that the CSS standard defines "reference pixel" as "the visual angle of one pixel on a device with a pixel density of 96 ppi and a distance from the reader of 28 inches", in other words 47 ppd. Using a device pixel to reference pixel ratio of two as discussed in this article means an angular resolution of 94 ppd, which is good enough for people with up to 1.5 vision, eg somewhere around half of the young adult population (eg primary target), or three quarters of the world population, which sounds like a good *minimum* target for *cheap* mass market devices.

For a computer monitor used at a distance of 28 inches (711 mm) that would be 192 ppi, for a tablet or phablet used at a distance of 12 inches (305 mm) that would be 448 ppi, and for a normal phone used at a distance of 8 inches (203 mm) that would be 672 ppi.

For *high-end* mass-market devices, I can see merit in increasing the pixel ratios up to 6 (Nyquist-theorem doubling of the 3*47=141 ppd discerned by the "best human eye"), and while I don't think exceeding a pixel ratio of 3 or 4 is ever going to be worth the extra money, I would still not compare it to the current audiophile hysteria, and would prefer if you didn't either, that might give some vindication and more fuel to the audiophiles :-P

Edmundson: High DPI Progress

Posted Mar 7, 2015 16:28 UTC (Sat) by sadboy (guest, #94691) [Link] (3 responses)

> On a side note, just what is the point of devices like the new Samsung Galaxy phones that have upwards of 500dpi? Anything more than 300 cannot be resolved by the best human eye.

Not true, just try looking at a 300dpi and a 500dpi screen side-by-side and you'll see, there's a huge difference. I'm not an anatomy expert, but the reason seems to be that the human eye is an analog device, not digital. I'm sure as you go higher in the dpi count there'll be increasing diminishing returns in terms of perceptible visual quality, but there isn't a magical hard cut-off point, and 300dpi is certainly too low.

Edmundson: High DPI Progress

Posted Mar 8, 2015 9:49 UTC (Sun) by nim-nim (subscriber, #34454) [Link] (2 responses)

The human eye peripheral vision is more sensitive than direct vision (evolutionary advantage : it helps detecting predators and preys that try to hide from us apes). I suppose that means that all pontifications that base themselves on ability to discern a pixel in direct vision are invalidated as soon as the image is not static and not seen directly.

Plus as others wrote the graphic stacks cheats left and right and adds approximations everywhere (font rendering is a good example). That's why good GPU tests do not limit themselves to FPSes but have humans check sample screenshots to verify the cheating is not too outrageous. Those errors tend to pile up. You need to increase pixel density from the minimum required by a perfect image to hide those approximations.

Edmundson: High DPI Progress

Posted Mar 9, 2015 22:57 UTC (Mon) by alankila (guest, #47141) [Link] (1 responses)

But only the fovea has the resolution, actually. I assure you that while peripheral vision may e.g. see better in the dark for some reason, it's virtually useless for high acuity tasks.

Edmundson: High DPI Progress

Posted Mar 12, 2015 0:01 UTC (Thu) by nix (subscriber, #2304) [Link]

while peripheral vision may e.g. see better in the dark for some reason

This is because rods require almost no light to activate them (one or two photons, rather than hundreds), but while they are smaller and much more numerous than cones, they are wired up differently: many of them converge on a single neuron. This helps to amplify the signal even more, but reduces the effective acuity (resolution) considerably.

And rods hugely predominate outside the macula (and even in some regions inside it), so they dominate peripheral vision.

Edmundson: High DPI Progress

Posted Mar 7, 2015 18:15 UTC (Sat) by vadim (subscriber, #35271) [Link]

Perhaps 500 ppi is pointless for cell phones, but I for one am not going to complain. The same displays get used in devices like the Oculus Rift, and there we still need all the pixels we can get.

The DK2 has the screen of a Galaxy Note 3 at 386 ppi, and when you put it on it looks very low res, and UI text in many games is barely readable.

I can't wait for a 4K version, but even seems like it won't look perfect.

Edmundson: High DPI Progress

Posted Mar 7, 2015 18:35 UTC (Sat) by flussence (guest, #85566) [Link] (13 responses)

Excess DPI beyond a certain point does allow some useful changes: it allows you to completely do away with pixel-based font hinting and antialiasing (of any kind, but particularly RGB-subpixel which doesn't play nice with anything but single stationary LCDs). There's not much performance to be gained from that in this era of GPU-rendered everything, but the text looks better - and you get something that begins to resemble device-independent rendering.

To demonstrate this using a slightly contrived example, https://developer.mozilla.org/en-US/docs/Web/CSS/transform looks awful at desktop resolution, but okay-ish on my 300dpi phone (though there's still *something* visibly wonky there).

Edmundson: High DPI Progress

Posted Mar 8, 2015 4:45 UTC (Sun) by roc (subscriber, #30627) [Link]

Eliminating antialiasing and the need to align solid edges to device pixels would let us dramatically simplify the graphics stack.

Edmundson: High DPI Progress

Posted Mar 8, 2015 4:55 UTC (Sun) by butlerm (subscriber, #13312) [Link]

That actually looks very nice in Chrome on Windows with a 96 dpi CRT display, probably because they are doing extensive anti-aliasing. It looks sub par as you say in Firefox, with no evidence of any kind of filtering - not yet anyway.

I have often thought that computers should render at some fixed multiple of the output resolution and filter it down in hardware, as a brute force solution to aliasing problems of all types.

Edmundson: High DPI Progress

Posted Mar 9, 2015 7:58 UTC (Mon) by epa (subscriber, #39769) [Link] (8 responses)

Couldn't you get those benefits by rendering to a large framebuffer and then having the hardware downsample it (with anti-aliasing) to a smaller screen?

Edmundson: High DPI Progress

Posted Mar 9, 2015 9:39 UTC (Mon) by ledow (guest, #11753) [Link] (7 responses)

There's a point at which doing that loses information, and the computer needs to be aware when that is or you end up with blurry and unreadable text and even interface, which isn't great when you're trying to log off to fix it.

Font-hinting is an incredibly precise art, where a single font size can be told exact pixels to turn on and off precisely because "just scaling down" breaks fonts to make them unreadable without it. Get into rotations and anti-aliasing on top of that and it quickly becomes a mess.

Try it yourself. Render some text at some enormous resolution and then shrink it to be the same size as an equivalent 9pt text. It'll look like junk and certain characters will just blur into a mass or have odd pixels. Even with anti-aliasing and font-hinting the two aren't equivalent.

This is also what kills part of the "scalable everything" desktops. As soon as you turn a large font vector into a smaller vector, of course the vectors are perfectly representations but the bitmap rendering of them looks atrocious.

High-dpi solves this only by "brute force" in that you're not shrinking down to exactly 9 pixels to make a 9pt font any more, but it's not as simple as just shrinking a large framebuffer down.

And that's probably one of the most memory-costly ways of rendering, and the smaller the final screen the more processing required!

Edmundson: High DPI Progress

Posted Mar 9, 2015 9:50 UTC (Mon) by epa (subscriber, #39769) [Link] (6 responses)

You're right - font hinting is difficult and a small face isn't just a scaled-down version of a large one, even with the best possible scaling and anti-aliasing. However, that problem doesn't entirely go away with high-dpi screens. You probably still want the physically smaller version of a letter to have a slightly different shape, even if it's big in pixel terms.

I agree that rendering a big framebuffer and shrinking it down is memory-hungry and slow. I was addressing the grandparent point that high-dpi rendering could lead to simpler code because there is no need to align to pixel boundaries and anti-alias. Could you not get the same code simplification (and the same higher memory usage) by rendering a big image and shrinking it? As you point out, the answer is 'not quite'. Anti-aliasing is not a magic bullet that will fix pixel alignment issues.

I wonder if some moderately intelligent sharpening might work? So you render a huge image without regard for pixel alignment, and then in hardware it is scaled down and sharpened, which takes care of snapping lines to the nearest pixel boundary. So the software can be relatively sloppy and just let a postprocessing stage clean up the final result. Perhaps that would never be acceptable for text, but it might work for vector graphics.

Edmundson: High DPI Progress

Posted Mar 9, 2015 10:04 UTC (Mon) by rsidd (subscriber, #2582) [Link] (2 responses)

Fonts are defined in point sizes. In modern typography, a point is 1/72 of an inch. An 8point font needs to be different from 10pt, 12pt, etc -- larger point sizes can be "scaled up" but smaller pointsizes aren't merely "scaled down", they look different to be more readable. What is really required is for the device to "know" how many pixels are in one typographic point, and communicate that to the rendering program. Android has a "dpi" setting that can be changed via an init file (though usually it requires creating a new boot image to change it). I'm not sure whether the font system obeys it in a sensible way, though.

Edmundson: High DPI Progress

Posted Mar 9, 2015 10:08 UTC (Mon) by rsidd (subscriber, #2582) [Link]

Replying to myself -- the difference in different-sized fonts isn't merely because of screen resolution and blurring, it applies even to printed text because the eye finds it hard to read, say, 12pt Times Roman shrunk to 6pt: it looks too squished together, the serifs aren't discernible, etc. TeX (with Metafont) was one of the first computer-typesetting programs to get this right.

Edmundson: High DPI Progress

Posted Mar 9, 2015 11:31 UTC (Mon) by epa (subscriber, #39769) [Link]

Yes, the different glyphs for different font sizes are what I was referring to. However, it's not just about knowing how many pixels are in one typographic point - at least not for WYSIWYG publishing and design. If you are editing a document where 8 point text is used for footnotes, then 8 point glyphs will be used. If you zoom in to 300% magnification the same glyphs should be used but just shown larger.

But most documents are not a screen preview of a fixed size 'page' intended for printing on paper. In particular, Web pages aren't, so I would expect the zoom in and out functions in the web browser to change the glyph shapes of text to keep it readable as the size changes.

Edmundson: High DPI Progress

Posted Mar 9, 2015 23:09 UTC (Mon) by alankila (guest, #47141) [Link] (2 responses)

> I wonder if some moderately intelligent sharpening might work?

I've often wondered the same thing. On reducing size of a bitmap, it is relatively easy to preserve the average amount of light emitted by the pixels that are combined into the target pixels, but what is harder is preserving the contrast. E.g, if you have pixels of white and black side by side, you have a high-contrast image of vertical stripes. Shrink it by factor of 2, and you receive uniform gray blob with RGB value of approximately 187/255 if you honor sRGB component brightness curve, and don't just average the component values. However, all contrast is lost.

A tradeoff might be useful, then. A mechanism to preserve contrast would have to do something rather weird like measure the difference signal between pixels, and attempt to preserve that as well, while still keeping the brightness average intact. In any event, it would produce severe distortion in various cases, but I feel that there could be a small chance that a contrast-preserving approach might be good for something in non-pathological cases.

Edmundson: High DPI Progress

Posted Mar 9, 2015 23:15 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

You can get most of the way there by using gamma-corrected scaling: http://entropymine.com/imageworsener/gamma/

Edmundson: High DPI Progress

Posted Mar 10, 2015 15:20 UTC (Tue) by hthoma (subscriber, #4743) [Link]

> You can get most of the way there by using gamma-corrected scaling: http://entropymine.com/imageworsener/gamma/

I don't think so. alankila already applied scaling in linear domain (gamma-corrected) in his example:

> Shrink it by factor of 2, and you receive uniform gray blob with RGB value of approximately 187/255 if you honor sRGB component brightness curve

Edmundson: High DPI Progress

Posted Mar 9, 2015 8:14 UTC (Mon) by rsidd (subscriber, #2582) [Link] (1 responses)

Hm. On linux with a 1920x1080 17" monitor, viewed from about 2 feet, I can see hardly any difference in the rotated text vs the regular kind, on either firefox or chrome. If I look very hard, the chrome version seems a bit sharper but it could just be my mind influenced by a previous comment. Using xmag, I find that chrome is subpixel-hinting the rotated text (apparently it's specified in my font config though I'd never checked) and firefox isn't (though it hints the regular text). But other than the hinting I can't tell any difference in the two rendered texts.

Regarding other comments above, motion artifacts tend to be issues related to many things -- GPU, frame rate, codec -- and paradoxically 24fps movies often look better (less judder in particular on panning) at lower resolutions than higher! Nothing I read above convinced me that >300dpi benefits any phone user.

Edmundson: High DPI Progress

Posted Mar 9, 2015 17:43 UTC (Mon) by flussence (guest, #85566) [Link]

I guess it depends on user settings (which contributes to the problem I'm describing) - on my system with somewhat tweaked fontconfig settings, the angled text has a pronounced zig-zag pattern between each character's alignment.

But I'm not too hung up on static image quality, and my personal preference is to agree with you on 300dpi being enough. However I *do* get annoyed when my browser can't scroll a static page at consistent 60fps...