Several times earlier this year, we covered Apple's work on "HiDPI" modes in OS X Lion for supporting ultra high-resolution displays offering greater pixel density with a similar increase in image quality to that seen with the iPhone's transition to a "Retina" display.
With new claims that Apple is set to release a new 15" MacBook Pro offering a resolution of 2880x1800 early next year, Apple's work on its HiDPI software support has also been gaining renewed attention. By doubling the resolution in each dimension over the existing 1440x900 MacBook Pro, Apple would achieve four times the number of pixels and provide developers with an easy way to scale existing artwork.
Evidence of Apple's continued work on HiDPI has shown up in developer builds of OS X 10.7.3, with the "Get Info" window for applications seeing the addition of an "Open in HIDPI mode" checkbox. But while that checkbox would presumably automatically use higher-resolution fonts and graphics that would display at the same absolute size as existing elements, it has not been functional in developer builds where it is present.
/article-new/2011/12/hidpi_10_7_3.jpg?lossy "hidpi_10_7_3")
With yesterday's release of Build 11D36 to developers, Apple has now removed that checkbox from the "Get Info" window entirely. While its removal may suggest a step backward in Apple's implementation of HiDPI support, it is routine for Apple to activate and deactivate portions of features as it works on them. Consequently, the mere change in the checkbox's visibility in the new build indicates that Apple is indeed likely actively working on the feature.
Top Rated Comments
While applications target a range of resolutions, displays generally have roughly the same pixel density, so user interface elements remain roughly the same size regardless of the resolution. So it's about the pixel density, not the absolute resolution.
The move to "Retina" display on computers dramatically increases the pixel density, and that's what needs to be accounted for so that user interface elements don't become unusably small.
By going with a doubling of pixels in each dimension, it becomes easy for the system to display a pixel-doubled version of a small element at the appropriate real-life size if the developers have not provided those elements at sufficient resolution within the application.
Oh, they don't? It's just me?
Ok...well...this is awkward.
That might be true for devices with known, fixed resolutions that are upgraded (ex: iPhone's 320x480 upgraded to the iPhone 4's 640x960), but it's completely pointless for computers which have various resolutions to begin with.
Nobody out there makes software that targets exactly 1440x900. Computer users use anything between 640x480 up to 2560x2048 (http://en.wikipedia.org/wiki/Computer_display_standard). Even the aspect ratio isn't fixed.
Additionally, the resolution doubling makes it a practical move for the development environment for Retina iPhone and iPad displays. For instance a Retina iPad graphic on a Retina MBP, will look the same as a non-Retina iPad graphic on a non-retina MBP. By consistently doubling the resolution of all products the only perceived difference for developers will be the clarity of the graphics.
This feature is nothing to do with the size of the display itself, but rather the pixel density. That matters just as much when the display size is unknown as when it is known. Your own quote makes the point: “scale existing artwork.” Not scale entire apps and UIs—we’ve met that challenge long ago. But scale the artwork, specifically.
Exactly! The challenges of a desktop app are NOT the same as for an iOS app.
Desktop apps already have to adapt to different “working area” sizes. Doubling the res doesn’t add that much to that challenge: the app doubles automatically and the “working area” remains the same. The app often need not even be aware that each pixel now means two. The OS will handle most of that.
It’s the assets within the app that are a challenge to scale, and using an even double IS a big help.