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.
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.
>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.
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
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
> 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.)
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.
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.
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
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.
> 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).
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
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..
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.
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.
> 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..
> 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.
[+] [-] kllrnohj|11 years ago|reply
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.
[+] [-] interpol_p|11 years ago|reply
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.
[+] [-] coldtea|11 years ago|reply
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.
[+] [-] zaksoup|11 years ago|reply
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
[+] [-] vyshane|11 years ago|reply
As for iOS's @1x vs. @2x images, think of them as your drawable-*dpi resources on Android.
[+] [-] cmelbye|11 years ago|reply
[+] [-] abalone|11 years ago|reply
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.
[+] [-] vor_|11 years ago|reply
[+] [-] moca|11 years ago|reply
[+] [-] bsaul|11 years ago|reply
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.
[+] [-] dep_b|11 years ago|reply
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.
[+] [-] lpsz|11 years ago|reply
[1] https://github.com/Masonry/Masonry
[+] [-] mahyarm|11 years ago|reply
If you don't believe me, look at this blog article that measures it: http://floriankugler.com/blog/2013/4/21/auto-layout-performa...
[+] [-] Tepix|11 years ago|reply
[+] [-] guelo|11 years ago|reply
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|11 years ago|reply
My grock of the article is that there will be artifacts, its just that they are difficult to notice at that pixel density.
[+] [-] x0054|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] serve_yay|11 years ago|reply
[+] [-] Dylan16807|11 years ago|reply
[+] [-] veidr|11 years ago|reply
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|11 years ago|reply
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|11 years ago|reply
[+] [-] Tepix|11 years ago|reply
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.
[+] [-] forrestthewoods|11 years ago|reply
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
[+] [-] TheCoreh|11 years ago|reply
[+] [-] devindotcom|11 years ago|reply
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|11 years ago|reply
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).
[+] [-] 0x0|11 years ago|reply
[+] [-] anon4|11 years ago|reply
[+] [-] smackfu|11 years ago|reply
[+] [-] bvrlt|11 years ago|reply
[+] [-] abyx|11 years ago|reply
[+] [-] shurcooL|11 years ago|reply
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/
[+] [-] lutusp|11 years ago|reply
Gee -- what's wrong with y = √(w² + h²)? It's much easier to interpret.
[+] [-] asadotzler|11 years ago|reply
[+] [-] barrystaes|11 years ago|reply
[+] [-] 2mur|11 years ago|reply
Raster-based pixel manipulation applications suck in this brave new hidpi world!
[+] [-] sarunw|11 years ago|reply
Really confusing.
[+] [-] venaoy|11 years ago|reply
[+] [-] bsimpson|11 years ago|reply
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|11 years ago|reply
[+] [-] Tepix|11 years ago|reply
[+] [-] QuadDamaged|11 years ago|reply
[+] [-] kalleboo|11 years ago|reply
[+] [-] jokoon|11 years ago|reply
[+] [-] Padding|11 years ago|reply
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..
[+] [-] lutusp|11 years ago|reply
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.
[+] [-] Keyframe|11 years ago|reply