
iPhone 6 Screens Demystified - melancton
http://www.paintcodeapp.com/news/iphone-6-screens-demystified
======
fidotron
This fuss about the iPhone screens is, to me at least, hilarious.

A good part of my career has been being the "Android guy" in organisations
where for better or worse the products would de facto lead on iOS. The number
one headache was designers pushing "pixel perfect design" which is doable on
Android, but is a pointless headache when your tiny screen is 720p or higher.

The fact Apple have a phone coming out for which it is actually impossible is
going to send a lot of these people into a confused fit. If this was how
Android worked it would be criticised to the hills, but because it's Apple
they can't.

~~~
MCRed
Since the points are rendered in pixel-perfect form and then down sampled on
the iPhone 6+, the only potential loss of fidelity is in the downsampling
step. Since we're in an age of not even being able to see pixels, there should
be no fidelity loss. The image displayed will be rendered at a higher
resolution than the display, and thus every pixel on the ultimate display will
be "perfect". Back when pixels were big enough to see, I was one of those
"pixel perfect" people too. You had to get it right, or the error was
noticeable. With retina displays, this is much less of an issue. (to me at
least)

I have seen android devices advertised with 4k displays at a 4-5" diagonal
form actor. That doesn't make sense to me, because beyond 300dpi there isn't
much point in higher pixel density. Yes, it makes sense for Apple to choose
this size display (as 1080p is a commodity size).

The real issue is, if you want to compare the platforms, which platform has
better resolution independence support.

I won't criticize android on this, but I will say that the iOS reliance on
PNGs has gone on way too long. 2x was a decent solution for photographs... but
we should have moved to SVG or some vector format as a native format in iOS
several years ago.

~~~
mrb
_" there should be no fidelity loss"_

Heh. Yes there will be, most notably on webpages, for example those with box
borders defined as "1px solid" lines. The lines will look fuzzy and unequal.
Check the last image at
[http://www.paintcodeapp.com/content/news/2014-09-11_iphone-6...](http://www.paintcodeapp.com/content/news/2014-09-11_iphone-6-screens-
demystified/line.svg) : it shows a "1 CSS pixel" line rendered as 2 black
lines + 2 grey lines (one of the greys is very, very light). Some lines will
not be interpolated the same way: some will be 2 black lines + 1 grey line,
some will be 1 black line + 2 grey lines, and the shade of the 2 greys will be
unequal and will vary depending on their precise alignment on the 1080p
physical grid. The end result is that some lines will look slightly
thinner/lighter or slightly thicker/darker than others. Heck, on my Nexus 5
which has an even higher PPI (445 PPI) than the iPhone 6+ (401 PPI) I can
still clearly notice this effect, when holding the phone at arm's length (and
I don't even have 20/20 vision), when simulating the downsampling that the 6+
is going to have to do. I can do it by zooming out[1] to simulate an effective
pixel ratio of ~2.61, which is equivalent to what the iPhone 6+ is really
doing graphically (1080 physical pixels wide / 414 logical pixels wide =
~2.61).

Contrast this with most Android devices where it _is_ possible to get pixel
perfect rendering because most (but not all) of them use a non-fractional
pixel ratio (1.0, or 2.0, or 3.0, or 4.0) and to my knowledge none do
downsampling (though with thousand of devices on the market I am sure 1 or 2
obscure models do it).

[1] If you have a 1080p Android device with a pixel ratio of 3.0 (eg. Nexus 5,
LG G2, Galaxy S4, HTC One M7, etc), you can simulate the downsampling of the
iPhone 6+ by zooming out in your browser by a factor of 360/414 = 0.8696

Edit: I did NOT downvote you. I agree that for many apps it won't be
noticeable, but it will be in some apps. Many users spend a lot of time in the
browser, and many sites use 1px lines, and they _will_ be a distracting
artifact (unless Apple implemented a special hack to interpolate 1px lines in
the browser - maybe Safari bypasses downsampling and forcibly rounds them up
to 3 physical pixels, but then what about other browsers?)

~~~
nailer
Why wouldn't a 1px CSS line, shown with 3 pixels on iPhone 6+ per, downsampled
to HD (per the article) still look OK?

~~~
runeks
FWIW, here's how a 1 pixel line looks on my Nexus 5 (4.95" 1080p display):
[http://i.imgur.com/RmRHpit.png](http://i.imgur.com/RmRHpit.png)

Here's the web page with the 1 pixel line:
[http://jsfiddle.net/k0xep8pL/embedded/result/](http://jsfiddle.net/k0xep8pL/embedded/result/)

On my PC, the line is just a single pixel. On my Nexus 5 -- as you can see --
it's actually three lines, which are (from top to bottom): grey (RGB=134),
black (RGB=0), grey (RGB=156).

The impression I get, when looking at it on my phone, is a solid black line.
Bear in mind, that the width of the display is 61 millimeters, which means
that these three pixels take up only 0.17 millimeters on the screen.

------
0x0
I wonder if it will be possible to opt-in to 1:1 pixel rendering on the
iPhone6+ after all, particularly for opengl/metal/video playback. It seems the
downscale hack is mostly required for UIKit backwards compatibility and to
maintain approximately equal physical sizes for UI elements only.

Very nice visualization in the OP, by the way!

~~~
pilif
There must be a way. Otherwise the samples they have shown in the keynote of
the landscape mail with the split view or the "enhanced" CNN sample app would
never work as in the default mode outlined in this infographic, the screen
can't possibly offer any more real estate for UI than the smaller screens, but
the samples in the keynote were clearly showing more UI content.

~~~
0x0
The samples with the wide split screen are rendered at 1242x2208 (3x 414x736,
which is larger than any other iphone which is either 320x568 or 375x667) -
and then downscaled. My question was really about whether is it possible for
software to render framebuffers at 1080x1920 (3x 360x640) - perhaps bypassing
UIKit completely.

------
bla2
This is looking really nice. The "No Image" images on
[http://www.paintcodeapp.com/content/news/2014-09-11_iphone-6...](http://www.paintcodeapp.com/content/news/2014-09-11_iphone-6-screens-
demystified/textRendering_2x.png) look unintentional, though.

Edit: The 1x version looks fine:
[http://www.paintcodeapp.com/content/news/2014-09-11_iphone-6...](http://www.paintcodeapp.com/content/news/2014-09-11_iphone-6-screens-
demystified/textRendering.png) So this post only looks broken on retina
screens, which is a bit ironic :-)

------
solutionyogi
An infographic which conveys a complicated information in easy to understand
form. More of this please!

------
ianlevesque
I know it's dangerous to armchair speculate about Apple's moves, but it really
seems like they should have held out for a true 3x screen instead of
compromising on a 1080p. I certainly would never buy the 6+ after reading
about their cheesy resolution hack. It feels rushed and short term.

~~~
rayiner
I think it's actually pretty clever. Developers clearly have trouble writing
apps to support arbitrary scale factors. Resolution independence was supposed
to be a feature of Windows since Vista was codenamed "Longhorn" (before 2004),
and Windows is still a mess on higher-DPI screens 10 years later. Making it so
developers only have to think about 1x and 2x and 3x makes the task easier.

Also, look at it this way: with the diminishing returns of resolutions above
300 dpi, is it really a big deal that you won't get the absolute best use of
the iPhone 6+'s 400 dpi? Seems like a pretty reasonable trade-off to use that
extra resolution in a way that makes resolution-independence easier for
developers.

~~~
jarek
I'm imagining the commentariat's reaction to such a "pretty reasonable trade-
off" on a Nexus 5 or a Galaxy S4

~~~
rayiner
Aren't the commentariat always asking "what's the point of going to 1080p or
4k on a 5" display?"

~~~
jarek
We were until Android phones got higher DPI than retina iPhones ;)

------
morganvachon
I'm not a UX designer by any stretch, but as a consumer I can say that if
Apple can pull off the downsampling/downscaling correctly, good on them. I
have a Kindle Fire HDX 7", and recently upgraded to a Fire HDX 8.9". The
former is 1920x1200 and 323 PPI, the latter is 2560x1600 and 339 PPI. That's
not a huge difference in PPI in fact it's far less than the difference in the
two new iPhones, yet so many apps (mostly games) render incorrectly on the
larger Kindle, to the point that small text becomes unreadable.

If Apple can release two new phones with greater disparity and seemingly get
the app experience right, why can't Amazon? I don't use an iPhone but seeing
these explanations that break down how they pull off such a feat really
impresses me.

~~~
MCRed
I haven't worked in the Kindle division, but there is a huge cultural gulf
between Apple and Amazon. Apple is very much a software company (well they're
a design company that encompasses both hardware and software). They care a
great deal about getting software right. At WWDC each year they have a session
on how to do great software that illuminates a process that involves a lot of
design and upfront work before you begin coding. A process that virtually
nobody does these days. (I say these days because back in the 80s this is how
CS students were taught "write your program out in paper before writing it in
code". Nowadays nobody barely thinks about their work before they start
writing code, for the most part.)

This is the polar opposite of Amazon, which I worked for in the past.

Amazon is perceived as a high tech company but it is a retailer and its
management is the management of a retailer. Amazons engineering is overseen by
non-engineers and the company culture is highly political and focused on
making a show more than making a product. Quality is the last thing they
actually care about (when it comes to software.) You get ahead at Amazon with
press releases-- it never matters if your product makes no sense. (EG: Movie
listings on amazon.com, mail-order catalogs, literally scanned, and posted to
amazon.com, innumerable initiatives and features that were put up there
getting someone a promotion, only to have the team disappear in the next
quarterly company wide reorg and the result to just rot.)

This is why I would never buy a tech product from Amazon. They really don't
give a damn as a culture, and any engineer who gives a damn will not survive
long there (and will be punished).

Giving a damn about design and quality doesn't play well with stack ranking.

What plays into stack ranking is kissing your bosses peers butts, playing
political games and making splashy new features.

~~~
BugBrother
>> Nowadays nobody barely thinks about their work before they start writing
code, for the most part.

I am old enough to remember where this came from...

I used to do C for quite a while, then I made my hobby (Perl and scripting) my
day job.

If given a certain size of a problem while working alone, I used to sit down
and think for 1/2 a day or so, then develop (coding and also thinking more)
for a week or two.

After I went scripting, this didn't work.

Since I could over an afternoon throw together a solution to the same size of
problem which took a week in C, it was just not realistic to think first!

The best solution was to throw something together, look at it and then rewrite
it if I didn't like it. The sheer development speed felt like I had gotten a
sports car.

~~~
tracker1
Absolutely agreed... prototype-morph-prod is a faster cycle.. but on the same
lines, it means automated unit tests are more important the more complex
projects get. Which is why modular code and testing work really well with
scripting environments, and computing is fast enough.

With a modular approach, it also becomes easier to scale horizontally either
in the same server/system or a separate server/system. Either via HTTP, TCP,
0mq or another abstraction, if the interfaces are the same, the modular layers
can be replaced. This gets easier with async by default environments (node.js,
golang, etc), and I find it to be much harder with classic N-Tier (.Net,
Java). I'd rather use 0mq with node than wcf with .Net any day of the week.

~~~
BugBrother
Interesting point about scaling, thanks.

------
u124556
So if you want to watch a 1080 video on this device, the player will upscale
it to 1242 and then the hardware will downscale it to 1080 again? or will
there be some way to bypass all this?

~~~
MCRed
The downscaling in the info graphic is representational of how a developers
chrome is handled. Not of a "full screen" experience...

Or put another way, when you play a video, you let the OS take over the full
screen and there's no need for downsampling.

Its not like the downsampling is a permanent stage of some rendering pipeline
to the display.

------
adamfeldman
(1) Is it really a problem that apps can't be pixel perfect on the 6+? How
unsharp are we talking about? Are there workarounds such as device detection
and an additional set of image assets?

(2) Will Apple aim to re-enable pixel-perfection in next year's iPhone
release? Was this just a stopgap measure due to yield challenges inherent to
display manufacturing?

~~~
MCRed
1- We'll have to see a device to know for sure, but I expect his will not be a
problem at all. For my apps, I'm going to do nothing, but make sure we support
the additional point dimensions.

2- I think this is doubtful. The first time I saw a WWDC presentation about
Resolution Independant graphics was in 2003 (maybe 2002.) Apple's been
preparing for this time for a over a decade. The iPhone just was a bit too
skeumorphic in its early versions resulting in a focus on raster assets rather
than vector.

Either we're all going the Paintcode way (authors of this post) or Apple is
going to have to start taking CSS or SVG or some vector format for its assets.

I think this is more likely than tying displays to a rigid multiple of the
original iPhone screen size.

------
xngzng
Would be great to add 4" size of iPhone 5/5s/5c to the illustration.

~~~
scott_karana
Substitute its resolution and dimensions for the regular 6, then: it's got the
same DPI and the same 2x scaling, on a smaller screen.

------
yodsanklai
Stupid question, but why the point resolution for the iphone 6+ isn't a
perfect divider of the pixel resolutions like it is for the other iphones?

Since there is more than one point resolution anyway.

And also, how is it different for android devices?

~~~
MCRed
Not a stupid question as you've hit on the major strategic bit of news here
that most people, I think, are missing.

Displays are cut from larger pieces of display material at a given PPI. So
Apple focused on perfecting a 163PPI display material and then tended to use
it on multiple products. They'd do the same thing for the retina display
material as well (I think at one point the iPhone and iPad used the same
display material and it was just cut to different sizes in making the display)

Apple could do this because they work so closely with their display
manufacturers and they care so much about fidelity. It just happened that
doing rigid multiples of the original display size was convenient for software
as well.

However, displays have become more commoditized, especially retina resolution
ones (at the time it was introduced, Apple was the only one shipping these
kinds of displays in such volume) and Apple's volume has only increased over
the years.

So we're seeing a shift to more commodity display production, I believe,
because the commodity market has caught up with Apple's standards. Beyond 300
pixels per inch there isn't much advantage to higher density.

But there is a huge advantage to unit volumes of a display also used in
portable TVs or whatever.

The software cost of downscaling isn't significant at this point so it is an
economic change.

~~~
bzbarsky
That explains the pixel size, but not the point size. Why not make the logical
resolution 360x640 with perfect 3x upscale?

My best guess is because this would then be smaller than the iphone 6 size (in
points) at a larger physical size so everything would look "too big"...

~~~
femto113
I believe this is because Apple wants the logical size to correspond (roughly)
with physical size. This is particularly important for user interfaces. A
button needs to be sized for the human finger that is tapping it and thus
should be the same physical size on each device, which in turn means it should
take up a smaller percentage of the logical size of the bigger devices. The
only case I know of where they broke this was the iPad mini, which has the
same logical size as the larger iPad, and you may notice that everything on
the iPad mini is just smaller.

~~~
sirn
To be fair, iPad Mini has the same PPI as the original iPhone (163 PPI) and
iPad Mini Retina has the same PPI as the Retina iPhone (326 PPI) so it could
be argued that iPad is the only device where everything appears larger than
the rest.

------
sriku
They did it! This nice page explaining the resolution differences etc. made me
want to click the "paintcode" link at the bottom of the page. This is hard to
pull off well, and I think they did it.

~~~
dingdingdang
Exactly this, the article succeeds in making this seem so incredibly backwards
that you NEED their particular commercial third party tool to survive as a
developer ;) (hey, maybe its even true, I haven't the faintest)

------
TomAnthony
Cool diagram - helps to understand what can be a confusing topic for people
who don't actually do any dev on the platform.

I believe the 326 PPI for the original iPhone is incorrect. Should be 163, I
think.

------
natex
Note: On latest Chrome, I'm getting some clipping on the left text column. see
[http://imgur.com/jEAuB4A,YtVYC4T](http://imgur.com/jEAuB4A,YtVYC4T)

Nice diagram!

~~~
sampo
Looks like the images themselves are incorrectly cropped, so everyone should
get the same clipping, whatever browser they use:

[http://www.paintcodeapp.com/content/news/2014-09-11_iphone-6...](http://www.paintcodeapp.com/content/news/2014-09-11_iphone-6-screens-
demystified/process.svg)

------
josteink
TLDR: The Iphone 6 plus can never show a sharp picture, unless the
application-UI is adapted to be unsharp on all other displays.

~~~
MCRed
Not the case at all. Anyway, anything rendered into a retina resolution is
going to be quite sharp.

------
Too
Microsoft made a somewhat similar mistake(?) many years ago with WPF, a vector
UI framework supposed to handle a wide range of pixel densities. You could
frequently end up with lines that were 1.5pixels thick or located on a
fraction of a pixel which caused them to look very blurry. To fix this they
added a special flag called something like forcesnaptodevicepixels, which was
supposed to force certain lines to always be located on an exact device pixel.

------
UIZealot
For the 6+, why couldn't they use a 1600x900 screen at 2x and be done with it?
That'd be 800x450 points and 330 dpi, nice and easy. Rendering at 3x and then
down sampling to 1920x1080 seems like a lot of useless busy work for
absolutely no gain.

------
achille2
I still don't understand how the iphone6 can run existing apps while having
the same dpi as the iphone5 but with a larger screen.

~~~
hokkos
The screen is larger but each pixels are at the same distance of each other in
both phones.

------
felixgallo
can this be real? There's mandatory downsampling in every case, even if you
want to try to ship to be pixel perfect?

