The Curious Case of iPhone 6+ 1080p Display

https://medium.com/@brucewangsg/the-curious-case-of-iphone-6-1080p-display-b33dac5bbcb6

by jameshuynh • 12 years ago

191 127 12 years ago

medium.com

TheCoreh• 12 years ago

So it's essentially the same thing as the "Scaled" display modes of the Retina MacBook Pro. An interesting approach.

kllrnohj• 12 years ago

Just... no. So very no.

Apple cheats because they failed to build a true density independent UI toolkit that actually works. Thus you end up with hacks like this where the UI is in a permanent state of filtered hell because the UI toolkit is just broken.

Android has proved this can work, and work fantastically. The article tries to spin it as being broken somehow, but clearly they never actually worked with Android much because this all works so, so well.

You don't need whole multipliers when you work in DIPs instead of PX.

vyshane3• 12 years ago

iOS uses logical points, i.e. a DIP on Android.

As for iOS's @1x vs. @2x images, think of them as your drawable-*dpi resources on Android.

moca2• 12 years ago

iOS apps use fixed layout, so they can't scale up/down with different display sizes. Since iOS only did double density once so far before iPhone 6 Plus, apps are quite easy to handle it. Android has way more variety, which is a pain for app developers.

moca2• 12 years ago

Android UI system still uses pixel in many places, such as MotionEvent.getX(). It should just use DIPs everywhere, which would significantly cut coding complexity.

interpol_p4• 12 years ago

As the sibling comment states, iOS has used logical points from the very first retina device. And even before then it has never used integers for its UI toolkit coordinate system — there was always the support for fractional coordinates.

The point of the article is that the iPhone 6+ renders to a larger offscreen buffer and then downscales to a 1080p panel. This is the same as the higher resolution modes on Retina Macbook Pros.

mirsadm3• 12 years ago

I haven't developed on iOS in a while so I'm not sure what the state of layouts is at the moment. Why would they render to a higher resolution than scale down if the UI can work with the new native resolution? It doesn't make sense because the output will be worse and a hit to the battery life.

cmelbye3• 12 years ago

I don't think you really understand how iOS works. iOS uses points as its units, not pixels. One point on a retina display is two physical pixels. One point on a non-retina display is one physical pixel. To create a one pixel thick line on a retina display, it must be half a point thick.

zaksoup• 12 years ago

I fail to see how not having a working scalable UI framework has anything to do with this.

Furthermore, have you used auto layout in Xcode 6? Not sure what about it doesn't work. I've got an app in review right now that's ready to support iPhone 6 and 6+ without any extra work because of Autolayout. I'm not saying it's perfect, but I'm just not sure how you can claim that it plain doesn't work. Also not sure why that has anything to do with why they're scaling @3x down to 1080p

vor_• 12 years ago

CoreGraphics uses points, not pixels. Experienced Cocoa developers know to make sure their drawing is done on pixel boundaries to avoid blurry edges, and there are APIs to help with this.

abalone• 12 years ago

iOS does work in DIPs (it calls them points) not pixels.

And it does have a density independent UI toolkit. It just only had 2 densities until now, whole multiples of one another. Which made it a lot easier for developers to update a million apps in short order.

Now there's one more. But the "cheat" here of keeping it to a whole multiple from the dev perspective is undoubtably an intentional choice to keep it easy for developers to adopt it. Which is smart when your platform has a lot of apps and you want them all to work perfectly on all devices.

Compare that to six dpi levels for Android. It can theoretically accommodate a greater diversity of devices but developer support for them is scattershot.

coldtea4• 12 years ago

Android has proved this can work, and work fantastically.

I've used a couple of Android devices, with latest-ish OS versions and "Fantastically" is not a word I'd use in relation to their "density independent" operation, and GUIs in general.

You don't need whole multipliers when you work in DIPs instead of PX.

You don't work in PX in iOS either. There have been logical units enforced from even before Android had a hi-DPI device available...

This is more about image (bitmap) assets apps have to use, and how they best adapt.

untog2• 12 years ago

I've used a couple of Android devices, with latest-ish OS versions and "Fantastically" is not a word I'd use in relation to their "density independent" operation

Care to state why?

veidr2• 12 years ago

As an end user, I'm a fan of Apple's 'scaled resolution' solution. My Apple notebook renders the screen in memory at 3840 x 2160 and then scales that to fit the 2880 x 1800 physical display. The benefit of this approach is that you can smoothly scale the UI to suit your age/eyesight.

When working, I keep mine set to smallest/most-information setting available by default (dubbed "Looks like 1920x1200"), but when relaxing I often give my tired 40-year-old eyes a break by bumping it down to "Looks like 1680 x 1050" and making everything uniformly bigger and easier to read.

When you look closely, of course it doesn't look as good as an exact match to the display native resolution does, but it looks pretty great. I think it will look even better on the 401ppi iPhone 6+ display, and the increasingly high-res screens of the future.

Tying logical display resolution to actual physical pixel resolution is pretty 💡🙉 at this point.

captainmuon• 12 years ago

As an end user, I'm a fan of Apple's 'scaled resolution' solution. My Apple notebook renders the screen in memory at 3840 x 2160 and then scales that to fit the 2880 x 1800 physical display. The benefit of this approach is that you can smoothly scale the UI to suit your age/eyesight.

That's what Windows 8.1 does when you have two screens with very different DPI (physical). When I connect my Yoga Pro 2 (with "retina"-like resolution) to my external 23" screen, it renders most applications at the high resolution, and then downscales them so they have the same size on both displays. The biggest problem with this approach is that crisp fonts on windows rely heavily on rgb sub-pixel-rendering. If your application doesn't directly paint to individual pixels, it can't control the subpixels, and can only do greyscale antialiasing, which looks very blurred (especially next to my Yoga Pro, where text looks like printed).

You can tell windows "I know what I'm doing, give me the raw pixels", but that comes with a whole lot of other problems, and I've never seen a single app get that right.

(What I'd really like as a developer would be to develop in (real) cm, inches, and em. Have them exactly match the physical sizes, for mobile and desktop screens (projectors would pretend to be a desktop). Have an option to "snap" lines to physical pixels. And on non-hidpi screens, render everything with subpixel-awareness, which triples your horizontal resolution.)

mbq• 12 years ago

Reasonable UI systems and not-overdesigned programs respect your UI font size setting and scale the rest accordingly, while equal resolutions allow hinting to do its job and produce a sharp output in an intelligent way. The brute-force approach of densifying monitors is a dirty hack and luckily doesn't scale at all.

veidr2• 12 years ago

I understand your position, but I don't agree with it at all.

"Reasonable" and "not-overdesigned" are rarely concerns that last into the future. And I don't think they even hold up given today's (high-end) technology.

Why on earth would font size be the arbiter of anything other than font size? Some programs don't even display text.

Logically, it makes a lot more sense to scale the entire display (or, sure, subsets of it). That's still technically challenging for some of today's systems, but not all of them. And it will be a vanishingly small number of them as we move into the future.

higherpurpose2• 12 years ago

Oh god not another "Apple made the iPhone 3.5" which is the perfect size" type of post.

There's no brilliant magic golden ratio formula behind Apple choosing 1080p. They simply wanted to choose a "regular" resolution for once, while still being bigger than 326 PPI.

If 720p would've been more than 326 PPI for the 4.7" one, they would've chosen that, too. The reason they didn't is because 720p is less than 326 PPI, and they didn't want to have 1,000 headlines out there say how "iPhone 6 has less pixel density than previous iPhones".

In my opinion they should've done that anyway, and end it with the stupid resolutions that Apple keeps using just because they didn't have the foresight to add resolution scaling early on to iOS, because they never imaged they could be building any other mobile device that isn't 3.5" in size. They messed up the "perfect scaling" for developers with 1080p on the Plus anyway. They could've done it on the smaller one, too. It's silly that they didn't do it.

retroencabulato• 12 years ago

Did you even read the article?

psychometry• 12 years ago

And with all this added screen real estate, you're still limited to 4 apps/row. Absurd.

bsimpson2• 12 years ago

Is DPI really a term in the iOS community? I thought DPI was a holdover from the print-era, and the politically-correct term was PPI (pixels-per-inch - not "physical" pixels per inch).

I've heard 1x pixels called "device-independent pixels", "CSS pixels", and "points"; but I've never seriously heard the term "device-pixels-per-inch" until this article.

detrino• 12 years ago

I really don't think it matters if you call them "dots per inch" or "pixels per inch".

Tepix3• 12 years ago

Everyone uses the term DPI for displays even if the correct term is PPI. It's not worth fighting about...

bsimpson2• 12 years ago

I don't mind people using the term DPI. The part that confused me is that the OP is drawing a distinction between them.

In my mind DPI == "dots per inch", PPI == "pixels per inch", and they measure the same thing (although some people frown upon using DPI in a digital context). The author redefines them to mean "device pixels per inch" and "physical pixels per inch", where PPI / devicePixelRatio == DPI. I wasn't sure if that's an OP-thing or an iOS thing.

shurcooL• 12 years ago

Very interesting approach. Like others said, the best way to describe is like using the higher resolution (scaled) mode on a Retina MBP.

I wanted to share pxcalc [1] for anyone doing DPI/PPI calculations, please be aware it exists (and it's awesome).

[1] http://pxcalc.com/

forrestthewoods2• 12 years ago

Another possibility for the lower res is perf. I think it's quite possible the 6+ will have the worst per pixel perf of any modern iOS device. In the conference they, I believe, bragged ~38% more pixels on the 6 and 170% more in the 6+. But the GPU is only 50% faster!

The iPhone 4 and ipad3 both suffered seriously by having 4x the pixels as their predecessor but only 2x the GPU. Mostly games suffered but it's still an issue elsewhere with fancy animations, transparency, etc.

But this is all speculatory theorycrafting at this point

mirsadm3• 12 years ago

The performance should be comparable to the iPad. They share the same SOC.

forrestthewoods2• 12 years ago

...no? 6 and 6+ are both A8. 5s, Ipad air and mini retina are a7. I believe air is clocked slightly higher tha 5s, 1.3ghz vs 1.2.

I think without question the 6+ will have worse per pixel perf than the 6. It would be even more worse if the screen were even more higher res.

That's not enough to make or break anything. But it's got to be another consideration.

pdpi• 12 years ago

That makes no sense to me. If that were the issue, they wouldn't use the larger frame buffer internally, which (AFAIK) is what dictates graphics performance insofar as it depends on display resolution.

guelo• 12 years ago

He glosses over the 6's resolution of 750x1334 vs the 5's 640x1136. Will 2x image assets be slightly blown up for the bigger screen? And what about the very slightly thinner aspect ratio?

As for "downsampling" of new 3x assets, the main image processing artifact to look out for is moire which happens to images with small repeated details. There are techniques to mitigate these artifacts but it will have to be a very smart algorithm to avoid artifacts in all cases.

OTOH, Android seems to have no problem handling small resizings of images within their size buckets system.

seanmcdirmid• 12 years ago

The iPhone 6 remains at 2X, just with more virtual pixels to work with.

My grock of the article is that there will be artifacts, its just that they are difficult to notice at that pixel density.

x00542• 12 years ago

Wouldn't the apps simply have the 1x, 2x, and 3x bundled in. This means the size of apps is going to grow, yet again. Yey...... As for iPhone 5 vs 6. I think legacy apps, games mostly, would be blown up. Anything that uses standard UI widgets would be starched to fill the screen. So in a list view you see more lines, in a text box more characters, etc. I hope that's the solution, at least.

bvrlt• 12 years ago

This really needs a TLDR.

darylteo• 12 years ago

There is one.

JBiserkov• 12 years ago

... at the bottom.

lucozade• 12 years ago

Retina displays have 2 physical pixels per logical pixel. The 6+ has 3x. However, the screen resolution isn't quite high enough for that so there is hardware downsampling. The author thinks that it'll look ok though.

idlewords• 12 years ago

God bless you

lutusp3• 12 years ago

Quote: "Calculating diagonal pixel is easy, following this formula: SquareRoot(w x w + h x h)."

Gee -- what's wrong with y = √(w² + h²)? It's much easier to interpret.

asadotzler• 12 years ago

maybe because you can't easily type that into a calculator like the one in Spotlight or google.com?

lutusp3• 12 years ago

Fair enough, in that case:

y = sqrt(w^2 + h^2)

QuadDamaged• 12 years ago

I haven't had the time to look at the docs but shall I start shipping art assets as foo@3x.png ?

kalleboo• 12 years ago

Yep. Xcode has also added 3x slots to xcassets files.

bsaul2• 12 years ago

As an ios dev, i know autolayout exists and lets you somehow manage the different resolutions if you manage to change your set of mind ( no more .frame = or .center= to change the location of a view dynamically but update constraints instead), and get away with the ugliest thing in the ios api that are constraint string expressions ( which almost made me throw up the first time i saw them).

But let's face it, that's one less thing we can mock Android devs about. Pixel perfect Wysiwyg ui building in interface builder has one foot in the grave.

Tepix3• 12 years ago

It's not just a matter of layout, it's also a matter of making sure that UI elements are not too small and not too large.

paulojreis2• 12 years ago

That seems like the only thing that they managed to keep - the assured physical dimensions of UI elements. The 44 point as a minimum guideline for tappable button size is valid for all resolutions (4:3 1x, 4:3 2x, 16:9 2x, 16:9 3x).

P.S. At least on the iPhone. The iPad mini (sporting the same resolution as the physically bigger brothers) will produce smaller UI elements.

lpsz• 12 years ago

FWIW, there are frameworks out there to make writing NSLayoutConstraints much more sensible. For example [1]

[1] https://github.com/Masonry/Masonry

iamraymondc• 12 years ago

Hopefully apple has updated the storyboard tools to do all of the layout constraints. I remember back in xcode5, there were some constraints that were only possible via code :(

dep_b3• 12 years ago

It's really time to dump those code views son. Interface Builder gives you all the tools you need to do it and works reliable, gives a LOT of feedback on your constraints when you build them.

You should learn auto layouts using Interface Builders, otherwise it's a nightmare because you're not getting the feedback you need to learn it right in the first place.

You need to start using priorities right, specially when you are doing >=, <= constraints you also need to add a low prio == constraint. It's not that hard, but you will be really frustrated if you keep clinging on to your coded views.

Try to chop up your Storyboards if you work in teams. They shouldn't be so big that you have trouble following the flow on one monitor.

duaneb2• 12 years ago

You can't code review storyboards.

bsaul2• 12 years ago

i did, son. but now tell me how you do complex animations on subviews in an autolayout view without adding constraint by code.

mahyarm2• 12 years ago

If your getting edge cases, why don't you just write your own layoutSubviews method and avoid using constraints except for very basic things? It's relatively simple stuff to write, and is more performant than autolayout, since layoutSubviews is O(1)-ish while autolayout looks like it's O(n^2).

If you don't believe me, look at this blog article that measures it: http://floriankugler.com/blog/2013/4/21/auto-layout-performa...

0x02• 12 years ago

What would happen if you tried to draw a fullscreen 1:1 pixel tiled checkerboard pattern?

anon4• 12 years ago

Well if it's using 3x scaling, then writing one pixel will write a 3x3 block on a 1242x2208 buffer that gets downscaled to 1080x1920 yielding a result like this https://imgur.com/ZsJKxzV

0x02• 12 years ago

Hmm, what if the checkerboard pattern is at 1:1 (1x1 blocks)?

smackfu• 12 years ago

Moiré patterns probably.

barrystaes• 12 years ago

It not that they had a bright moment when going for a normal (power of two) resolution, its just that they have not done so up until now. And nobody except Apple used those technically suboptimal resolutions in mobile phones, with good reason..

Tepix3• 12 years ago

Apple is losing its advantage over Android regarding market fragmentation.

An iOS developer has to support eight different screens these days to cover all devices that will run iOS8:

* iPad 2

* iPad mini (the last non retina devices, same resolution, different DPI)

* iPhone 4S

* iPhone 5/5C/5S/iPod Touch 5th gen

* iPhone 6

* iPhone 6 Plus

* iPad 3/4/Air

* iPad Mini Retina (again, same resolution, different DPI)

Many devs will ignore the DPI differences between the iPad and the iPad mini, but that isn't ideal. I think the iPhone 6 Plus should have had a 1600x900 display to keep the DPI in line with the previous phones, however Apple was probably afraid to be compared unfavorably to the Android phones that have 1080p panels.

paulojreis2• 12 years ago

From my understanding, they did kept the DPI in line. A 44 point button will have the same physical size in all iPhones, including 6+. It will, however, require three graphical assets (if you intend to support non-retina).

However, as you point out, this is not true for the iPad.

xienze2• 12 years ago

Eh, that's not exactly how it works. You're confusing physical device resolution/size with the logical resolution that developers have to deal with. From a development perspective, with the exception that you have to make 1x, 2x, and (now) 3x bitmaps:

* iPad 2 = iPad Mini = iPad 3 = iPad 4 = iPad Air = iPad Mini Retina

* iPhone 5 = iPhone 5C = iPhone 5S = iPod Touch 5th gen

* iPhone 4S is a "sort of" outlier. If you're using the auto-layout stuff that's available it "just works" on a 5* phone. The exception is apps that aren't widget-based, like games.

* iPhone 6 and 6+ seem to have different logical resolutions, so there's that. But again, auto-layout helps here.

The "different DPI" thing is irrelevant. Get the UI elements to have the same size proportionally and you're set.

higherpurpose2• 12 years ago

Which is not much different than Android, despite all the sensationalism about having to support "18,000 different devices".

You have to support only 6 pretty much, which comes quite close to how many you have to support on iOS right now (you mentioned 5):

ldpi (low) ~120dpi

mdpi (medium) ~160dpi

hdpi (high) ~240dpi

xhdpi (extra-high) ~320dpi

xxhdpi (extra-extra-high) ~480dpi

xxxhdpi (extra-extra-extra-high) ~640dpi

https://developer.android.com/guide/practices/screens_suppor...

coldtea4• 12 years ago

Apple is losing its advantage over Android regarding market fragmentation.

Android has 5000 devices, differing OS versions (half of the devices out there use a 2 to 3 year old OS), and differing hardware capabilities (including different qualities in stuff like sensors, some of them even being nearly useless).

And Apple is losing to that because it has "8 different" screens?

For one, you can support most of them (all iPads for example) with the exact same code plus 2 sets of bitmap assets: normal and 2x.

As for the iPhones, they transitioned without a hitch to 5 taller display, and the same will happen to 6/6+.

Noughmad• 12 years ago

Testing for 5000 devices isn't much different from testing for 8 devices. At some point you stop writing and testing for every configuration separately, and start grouping them, pretty much as you describe with one code and 3-5 sets of assets (counting both bitmaps and layouts).

untog2• 12 years ago

differing OS versions (half of the devices out there use a 2 to 3 year old OS)

That stat is pretty out of date by now. Android <= 2 now only accounts for 12% of devices, and most app devs aren't targeting it any more.

And Android might have 5000 devices, but it doesn't have 5000 screen sizes. Still more than Apple has, but hardly 4992 more.

http://www.androidheadlines.com/2014/09/androids-kitkat-clos...

scott_karana• 12 years ago

Not to mention Bluetooth support: 4.0 wasn't officially supported until Android 4.4 (IIRC), and you had to rely on OEM-specific libraries for Bluetooth beforehand.

rythie• 12 years ago

In terms of layout there only 5 resolutions (ignoring DPIs): https://rythie.com/ios-sizes/ and then assets in @x2 @x3 versions

archagon• 12 years ago

In theory. In practice, you could get away with supporting just iPhone and iPad layouts, or one or the other if not going Universal. (And Autolayout helps you move forward when you're ready pretty easily.) Also, you don't have to worry about things like graphics hardware differences, poorly-implemented APIs, and OS versions nearly as much.

Is it even possible to tell the difference between the iPad and iPad Mini in software? When it first came out, it wasn't, on purpose.

rsynnott• 12 years ago

Many devs will ignore the DPI differences between the iPad and the iPad mini, but that isn't ideal.

Most developers do ignore this, and Apple encourages ignoring it. Incidentally, this is why tap target sizes (button sizes and such) are a bit bigger on a full-sized iPad than on an iPhone; to allow for the scale-down.

macspoofing2• 12 years ago

I'm sorry you're wrong, different screen-sizes (and resolutions) are NOT market fragmentation. It's not hard to handle them and we've been writing phone and tablet apps for years now, so that's a solved problem.

API/Platform fragmentation is the big problem. Supporting multiple APIs and gracefully degrading to older versions is much harder than being able to scale your UI. Apple has been pretty good with keeping customers devices as current as possible. Android, not so much.

Many devs will ignore the DPI differences between the iPad and the iPad mini

That's because iOS-only developers were spoiled and got lazy. If your app breaks because now it has to work with a slightly different aspect ratio, or doesn't take advantage of a higer DPI screen, that's your failing.

jayvanguard2• 12 years ago

I'm sorry you're wrong, different screen-sizes (and resolutions) are NOT market fragmentation. It's not hard to handle them and we've been writing phone and tablet apps for years now, so that's a solved problem.

Yes it is fragmentation. Just because it is "solved", doesn't mean it doesn't create extra work, extra bugs, and from a test matrix perspective, more compromises.

king_jester• 12 years ago

API/Platform fragmentation is the big problem. Supporting multiple APIs and gracefully degrading to older versions is much harder than being able to scale your UI. Apple has been pretty good with keeping customers devices as current as possible. Android, not so much.

This is highly dependent on which kind of APIs you are interacting with. Most API families are part of Google Play Services now which means they are generally available back to 2.3. Framework API differences between platforms are generally small and haven't been much trouble to work with, although some types of hardware interaction changed significantly between some platform levels (e.g. audio).

lostgame• 12 years ago

'Market Fragmentation' != Device resolutions.

lrn2terms

gurkendoktor• 12 years ago

As an iPhone app developer, I agree with your first sentence, but the resolutions are actually the smallest issue. In addition to what has been said in the sibling replies,

* Designing for iPhone 4/4S and 5/5c/5s is almost the same, at least in portrait orientation. Most layouts are a little flexible vertically - and they have to be, because users might be in a call, or have the personal hotspot active, in which case the OS reserves some space for an additional status bar. Apps have to be flexible vertically, period. * It is much harder to support all the larger text sizes that are available in iOS 7. Much of the iOS UI is built on UITableViews, and these "tables" are terrible when it comes to line breaks. I have increased the text size and many apps can't handle it, including some of Apple's own. * If you are extra masochistic, enable "Button Shapes" and "Reduce White Point" in the Accessibility options in a custom-styled iOS 7 app. For example, this will darken tint colours, which can make buttons harder to read if they are placed over an image (which the OS will not darken).

mahyarm2• 12 years ago

To be honest, dealing with status bar height changes are far more annoying in iOS than having to support a few different resolution sizes.

jokoon3• 12 years ago

I don't understand how such high PPI really matter at all. I mean it increases battery usage, it costs more, and all you get is smoother text and smoother pictures on a less than 5 inch screen.

Padding• 12 years ago

all you get is smoother text and smoother pictures on a less than 5 inch screen.

I don't think smoother text (and pictures) is anything to be trivialized. I mean it actually looks much much nicer and (imho) comforting - I experience joy anytime I look at anything that's above the 100 or so ppi of average 1080p monitors.

People spend huge swaths of money on the looks of things that they'll hardly ever be looking at. Considering this, spending the money on a screen (i.e. something they'll litteraly be staring at for large periods of time) is actually a borderline-rational choice in comparision..

jokoon3• 12 years ago

I experience joy anytime I look at anything that's above the 100 or so ppi of average 1080p monitors.

I experience joy when I can go online and check my emails when I'm in the bus or outside.

lutusp3• 12 years ago

I don't understand how such high PPI really matter at all.

If there's more resolution than the display (or the observer's eye) can support, the extra resolution can be used to make diagonal lines look better (as one example), through a sophisticated drawing method that eliminates jaggies. I'm not saying this is always true, but it's on the list of options to exploit the extra resolution.

I mean it increases battery usage, it costs more, and all you get is smoother text and smoother pictures on a less than 5 inch screen.

That's pretty much it. But consider that people who buy Apple phones know they're not buying the least expensive, most cost-effective devices, so maybe they expect to get something not present in the bargain phones, like resolution that no one can possibly notice. Sort of like having a refrigerator whose light stays on when the door is closed.

Keyframe2• 12 years ago

For one, at 800dpi or so aliasing problems go away. With that kind of density, I presume, race for density will be done.

chadgeidel• 12 years ago

I had always heard it's in the 300 range. Phil Plait did an analysis back in the day using "display held one foot away" as the metric and determined that "average eyesight" could resolve 286 PPI. "Perfect eyesight" would bump it to 477 PPI.

http://blogs.discovermagazine.com/badastronomy/2010/06/10/re...

jokoon3• 12 years ago

that's an expensive way to solve a cheap problem, which has already been solved.

abyx• 12 years ago

Am I the only one that noticed the iPhone on the left is actually a 5s and not a 6?

2mur• 12 years ago

Anybody know what window.devicePixelRatio will report on the 6+?

Raster-based pixel manipulation applications suck in this brave new hidpi world!

serve_yay• 12 years ago

This write-up (also on the front page currently) is a lot simpler and focuses more on the actual dimensions, instead of frankly half-baked marketing analysis. http://www.paintcodeapp.com/news/iphone-6-screens-demystifie...

Dylan168073• 12 years ago

Thank you. I was so confused about where the number 1242 came from. The number 414 isn't in the entire article.

venaoy2• 12 years ago

That's because the author made a calculation mistake. He wrote "412" instead of "414".

devindotcom• 12 years ago

A simpler way to explain this is that for the iPhone 6, it really is a slightly larger iPhone 5 screen, like if you were moving from an 11" MacBook Air to a 13" one. But for the iPhone 6+, it's like moving from that 13" one to a 15" Retina MBP. And as we all know, the Retina Macbooks render at a higher internal resolution and then scale it down to the native one.

I do appreciate the technical explanation, but as Apple has done this before, for a quick explanation it's sufficient to point to the rMBP precedent.

mpweiher• 12 years ago

And as we all know, the Retina Macbooks render at a higher internal resolution and then scale it down to the native one.

I don't know that. Unless you're talking about scaled modes, which do resampling, the retina models render at the native resolution. They will scale apps by 2x that are not capable of rendering at the native resolution (not many).

sarunw2• 12 years ago

In article he mentioned 1242px by 2208px with 462ppi as 3x of 163ppi (original iPhone). Shouldn't it be 489ppi ?

Really confusing.

venaoy2• 12 years ago

Yep, another error. He also wrote 412px instead of 414px in some other location.

sarunw2• 12 years ago

Not quite an error (the calculation is correct). It just don't make sense for me why Apple come up with this magic 462ppi instead of 489ppi.

The Curious Case of iPhone 6+ 1080p Display

Related Stories