John Gruber analyzed the ramifications of an alleged 960×640 screen on the upcoming iPhone model:

Compare type on your iPhone or iPod Touch against the type in a glossy magazine. […] The next-gen iPhone is shooting for that caliber of resolution — not merely to exceed the resolution of competing devices, but to rival the optical quality of print.

I’m not sure what the software story will be for iPhone apps to take advantage of this increased resolution. If existing unmodified apps run pixel-doubled, they should look identical with the naked eye to how they look today on existing iPhone displays.

Marco Arment responds with skepticism about the value of such a move:

But I’m still puzzled about the 960 × 640 move, if it’s real. The iPhone is already the highest-DPI display that Apple sells, and to double its resolution is very expensive: the panel costs more, it’s likely to use more power, it places higher demand on the CPU for rendering, it needs much more memory for frame buffers and textures, and it incurs big costs on developers and Apple’s developer-tools and developer-support teams.

Let’s assume that Apple has a list of goals for the next phone, and a higher-resolution screen will help them to achieve them. Let’s not get carried away and start assuming that this means the high-resolution screen will be made available for general-purpose developer use.

Wouldn’t it be very Apple-like to use the higher-resolution screen as a mere implementation detail? Just because Apple’s putting a new screen in the phone, doesn’t mean they’ll let you have access to it. If they maintain a conceptual 480×320 screen for iPhones, there is very little of the increase in memory usage that Arment alludes to, there is zero change to complexity from a developer tools perspective, and there is no cost to developers in determining how or if their application should take advantage of a higher-resolution screen.

By applying the default pixel doubling as the baseline scenario for every app, they maintain 100% consistency in user experience across the current lineup of phones and the upcoming models. But on newer phones with high-resolution screens, Apple can take advantage of the screen at their discretion to pragmatically improve the user experience.

For example, if Apple applies this strategy, they can simply do the default bitmap doubling for all pixel-based drawing, but reap the benefits of the higher-resolution screen for all vector-based drawing. Vectors that are used e.g. to describe line art or the fine curves of a typeface, do not take up any more RAM when targeting a high-resolution screen than they do for a low-resolution screen, but when it comes time to draw them, they gobble up as much fidelity as you can throw at them.

A typical application running on a 960×640 screen will use the same amount of RAM as it does on a 480×320 screen, will have identical screen layout and user interaction behavior, but the fonts and vector art will be incredibly, dare I say magically, sharp and beautiful.

Update – A Catch!

John Siracusa explained to me through – a – series – of – tweets, how the story doesn’t play out so perfectly in reality.

Because the fidelity of any vector art is being compromised when it’s mapped to pixels, there will be subtle differences in the precise alignment of how these pixels end up falling on the higher-resolution screen vs. the lower-resolution one. In other words, the layout may change somewhat dramatically when, e.g., rendering a long line of text, or a complex, small vector illustration. If the application is designed with assumptions about the portion of the screen that content will take up, then the higher-resolution screen cannot dramatically alter that or it defies the developer’s design.

He’s got me worried that it’s a deal-breaker, but I leave it to Apple to demonstrate for us whether it is or not. I wonder if at some point the increased resolution becomes so high that it affords some compromise in the layout so that metrics continue to add up as expected without causing noticeable awkwardness in the rendering.

This entry was posted to iPhone, Links, Programming. Comments are closed. Thanks for reading!