Hacker News Reader

Comment by kllrnohj | Hacker News Reader

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.

View on HN

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.

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.

Actually no. The more pixels the screen has the more energy it requires to drive those pixels and so worse battery life. So by having a lower resolution screen and scaling down to fit that screen battery life is improved.

The alternative talked about here is not having the physical screen resolution of 2208x1242 but rather just rendering at 1080p without scaling down.

Displaying in the native resolution would lead to an even curiouser case where the iPhone 6's 4.7" screen displays more content than the iPhone 6+'s 5.5" screen (assuming integer scaling factors of 2x for the 6 and 3x for the 6+).

I do hope that there is some sort of programmable setting or API for enabling native resolution output so that games built with this option are rendering at 1080p and displaying at 1080p, or 1080p movies aren't needlessly being stretched and then downsampled. For legacy apps and not graphically intensive stuff it mostly makes sense to just display at 3x and scale down for simplicities sake, but if the option isn't otherwise there that seems pretty silly.

By rendering to a larger buffer they can ensure that any raster assets may use an integer scale factor between devices. If they rendered to the panel's native resolution (1080p) they'd probably have to use a 2.5x scale factor, which is not desirable.

The output will be slightly worse, but at 400 PPI you probably won't be able to tell without a magnifying glass. The current Retina MBPs do this in their higher res modes and it's pretty hard to notice.

On battery life: perhaps the tradeoff of using a 1080 panel outweighs the scaling.

Also it leaves the door open to switch to a full resolution native panel in an iPhone 7+ with no hit to existing apps or developers.

Huh, I don't know that much about GPU's, but surely they can render fractional pixels directly without downscaling shenanigans. Which actually means that GPU will convert full pixel values to fractional before rendering. Rendering to a larger buffer and then downscaling is actually a form of antialiasing, albeit an inefficient one (if I'm not wrong). Also, rendering without antialias would result in rounded full pixel values. Obviously, bitmaps will be downscaled on the GPU using whatever filters are set for them (just like before, if bitmap is larger than the target size).

It's not so much about the GPU rendering fractional pixels, it's that it makes it much trickier to create neat assets that work at non-integer scale factors. Generally you want to ensure your raster assets have details that lie on integer boundaries at all scale factors, throwing in a non-integer scale factor as a target makes it more difficult to do that.

>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'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?

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

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.

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.

This isn't correct. If you've ever resized an application window in OS X, it's likely that you've used autolayout. iOS has the same functionality. In addition to a flexible layout system, iOS has the concept of size classes which determine appropriate content to show based on display size.

But I can imagine that many iOS apps still use 'a fixed layout', as the parent comment stated (or perhaps at max use the old struts and springs mechanism). This may be quite a few and they could all break if Apple had not come up with the 'cheat', as the top comment called it.

I doubt that too many do, or at least many that are actively maintained.

The introduction of the taller iPhone 5 screen, and Apple's subsequent rejection of "letterboxed" apps (ones that don't make any use of the additional screen space) mean that most developers will almost certainly have switched to autolayout.

I still don't understand the "cheat". Any well-designed app that wants to take advantage of larger screen sizes on the new iPhones to display more content will use autolayout and the new size classes (compact and regular). There is no cheating involved.

For transition purposes, apps that haven't been updated yet will simply be scaled up (everything on screen will be slightly bigger). This is similar to when the iPhone 5 introduced a lengthened screen and apps were letterboxed until they submitted an update confirming that they were compatible with the larger screen.

iOS has always been able to do fluid layouts. It was possible with Springs and Struts (though a PITA), and from iOS 6 onwards has Auto Layout, which I personally find better (more declarative) than Android's box model.

I would also like to point out that there is a JailBrake tweak, FullForce, that lets you stretch most iPhone apps to iPad screen. Most iPhone apps can actually stretch and grow, and can actually do so pretty well. And, it worked even before auto layout. Apple, stupidly, did not allow legacy apps to auto stretch on iPhone 5 because (a) they wanted to force developers to update, and (b) they are paranoid about some things not working perfectly. A tweak like full force could have starched 90% of all iPhone 4 apps to iPhone 5 screen, but Apple would not allow it because of the 10% that would not work so well. But the software supports it, and to claim otherwise is silly.

I agree that it isn't as big a deal as some people are making out. But at the end of the day you can't disagree that it was a massive flaw from the beginning of the iPhone (and its days before it let people develop apps for it) driven likely by the megalomaniac supposition that if you build a phone you can't reach all parts with from your thumb: "no one's going to buy that."*

*http://goo.gl/pTwfws

Can't agree with this at all. Auto Layout can do some things that are very hard to do with Android layouts but for the common cases I find Android's layouts vastly more logical and maintainable than the typical Auto Layout mess. There are fewer things I dread more than opening up a complex xib file to dig into a complex Auto Layout scheme. Let the hunt & peck party begin!

I can open up an Android layout file and almost instantly understand how it works and what I have to do to change it.

It might be too late for your project, but I'd highly recommend using Masonry (https://github.com/Masonry/Masonry) for Autolayout. It's a DSL for specifying constraints that is far better than Apple's NSConstraint API and constraint language.

Since discovering it I've fallen in love with Autolayout and its abilities — where I used to dislike it before.

For me, it comes down to the fact that I find Auto Layout more declarative. I'm `saying what I mean` when I apply constraints - that can be done in code too, of course, although Xcode 6 is getting pretty good at surfacing that information. Whereas when I'm dealing with a box model I'm having to play compiler in my head. LinearLayout, RelativeLayout - these are terms that are optimised for the computer to understand. Constraints are the way we humans think about things. "Element A should always be 10 points to the left of Element B".

It's a bit like imperative vs. functional programming. In the former model, I have an idea in my head and I need to nest containers step by step to get to the final form. In the latter I'm simply building up a ruleset.

But like I said, that was my personal preference. I guess we'll have to differ on opinions ;)

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.

Reply on news.ycombinator.com