»

Higher Resolution iPhones

April 20th, 2010

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 throughaseriesoftweets, 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.

4 Responses to “Higher Resolution iPhones”

  1. Marco Arment Says:

    Great idea, Daniel.

    It would still be a nontrivial migration for certain features. For example, for one procedure in Instapaper, I copy the contents of the screen buffer and perform direct pixel manipulation. What the “right” thing for the OS to do in those contexts isn’t clear: does it give me the true raw pixel data, which has twice the resolution I was expecting, or does it render it down to what I think the resolution is (incurring an additional CPU and memory burden) before handing it to me?

    But, assuming that issues like that can be worked out, this would be a great solution, and I’d welcome it.

  2. Troy Gilbert Says:

    Come on, Daniel, you’re a programmer, how can you suggest that Apple could “magically” mix vector rendering and bitmap rendering, increasing the resolution of the vector stuff while pixel-doubling the bitmap stuff, and not have it impact the folks writing the apps and not impact memory and performance?

    Even on a platform designed with this goal in mind from the outset (i.e., Flash), this is a non-trivial issue that comes up quite often. On a lower-level platform like iPhone OS where developers have native code with fairly fine-grained access to the frame buffers this just couldn’t work seamlessly.

    And rendering vectors still requires that they be rasterized at some point, which eats CPU cycles and memory.

    More likely is that apps could choose to take advantage of it, or run in a pixel-doubled mode (like on iPad), but not some magical hybrid of the two…

  3. Jim Thorpe Says:

    Isn’t this rather closely tied in with the memory gripes that people have with the iPad? Isn’t the larger pixel-area causing the Safari tabs to fill memory faster and be reloaded more often? Sure, often the content itself will just remain the same memory-size (e.g. vector or type), but that’s not all that needs to be considered, is it?

  4. Vincent Gable Says:

    To play around with the resolution-independent magic built into Mac OS X (assuming you have developer tools installed):

    Open /Developer/Applications/Performance\ Tools/Quartz\ Debug.app, then under the Window menu choose UI Resolution, now move the slider up to 3 and relaunch apps to see how they take to it. Much of the standard UI chrome is scaled up magically, but there are clearly a lot of problems.

Comments are Closed.

Follow the Conversation

Stay up-to-date by subscribing to the Comments RSS Feed for this entry.