![](\"http:\/\/www.red-sweater.com\/blog\/images\/ResolutionSideSide.png\"\/)
\n<\/p>\nResolution independence is the notion that all graphics on a computer display should be zoomable to an arbitrary multiplier without losing quality. If you know even the slightest thing about computer graphics, you’ll understand that in a resolution independent world, bitmaps are out and vector graphics are in. Vector graphics can scale gracefully to an arbitrary resolution, while bitmap graphics inevitably lose quality.<\/p>\n
\nBitmaps specify a graphical image as a grid of colored dots that, when combined at high enough resolution, may create the illusion of a photorealistic image, or a smoothly curved contour. For the time being, we’re stuck with grids of pixels, because that’s how our monitors and (most) printers work. Over the course of computer history, bitmap graphics have gotten larger to accommodate increasing display resolutions. For instance, icons “looked fine” in Mac System 7 at 32 by 32 pixels, because most monitors were not more than 640 by 480. As monitor sizes grow, the standard sizes for icons and other graphics grow along with them. Suddenly the System 7 icon looks like crap when forced to participate in this modern world:\n<\/p>\n
\n\n<\/p>\n
\nSo, MarsEdit<\/a> pretty, Resorcerer<\/a> ugly, right? For now, anyway. Time marches on, and one day we’re sure to find ourselves struggling to appreciate the relatively low resolution of the MarsEdit icon, too. Look what happens if we quadruple the resolution (caveat, this is from the screen capture, not necessarily from the highest quality available in the MarsEdit bundle):\n<\/p>\n \n \nSuddenly the cracks are beginning to show. So what’s the big deal? Can’t we just continue to improve image quality as resolutions increase? We could, except that the limits of resolution are about to be completely blown away. Resolution independence will debut as a user-level feature in Mac OS X (and Windows Vista, as I understand it) giving users the ability to choose the resolution at which they wish to view any graphics on their screen. Apple has a few documents on this that are worth reviewing<\/p>\n What this means for developers is that every piece of bitmap graphics in your application is now liable to be zoomed to such a degree that it looks like ass. How much like ass? You can get a sneak peek at how well your graphics survive resolution independence by using a little-known feature of the Quartz Debug application (part of developer tools). Select “Show User Interface Resolution” from the Tools menu to see the following window:\n<\/p>\n \n \nYou’ll have to quit and relaunch your application to see it at the zoomed level. Now that you know how bad the problem is, what’s the solution? In order to prevent our graphics looking like ass, they themselves need to be resolution independent. This means they either need to be drawn on the fly, or created and saved in a vector-based format. Ugh! Lots of work. The good news is that lots of designers have been using vector-based art for their work for some time, and can probably accommodate the changes pretty easily. But if you’re a cheap hack like me, you’ve probably got lots of bitmaps around that will need to be revised.\n<\/p>\n \nPeter Hosey<\/a> noticed one such cheap bitmap in FlexTime 1.1<\/a>: the new pie-chart table header cell. It looks fine at 12×12 pixels, but let’s see what happens when resolution independence takes its toll:\n<\/p>\n \n \nYikes! Peter was nice enough to send along a solution, which was a small EPS source file that, when compiled into PDF, made a fast and resolution-independent graphic resource for my product. The only problem was I had some minor qualms with the exact size of the pie-wedge, and wasn’t comfortable enough in PostScript to easily make (or maintain) the changes. What the heck, I thought, why not do this programatically from Cocoa? I can use NSBezierPath to draw vector scaleable graphics on-the-fly at any resolution. I discovered, with Paul Kim’s<\/a> help, that NSCustomImageRep<\/a> would allow me to both do all the drawing on the fly, and take advantage of the conveniences of NSImage, such as being able to “setImage” on a table header cell. Let’s see how my pie icon survives zooming now:\n<\/p>\n \n \nWow! That’s pretty cool. I thought this technique for “resolution independent generated images” would be useful for others, so I thought I’d share some code. But surely you’d have no use for a quarter-filled pie. Let’s see, what would be truly useful. A piece of reusable code that will last through the decades, and never turn stale. I know! A little yellow guy!\n<\/p>\n \n \nLittleYellowGuy<\/a> contains an example application and Xcode project, demonstrating the creation of an NSImage that draws itself at full resolution for whatever size it’s set to. This code is available to you under the MIT license.\n<\/p>\n \nNow that my pies and little yellow guys are in order, I can turn my attention to the other vulnerabilities in my interface. Those brand-spanking-new toolbar icons I just designed using PhotoShop? Even they are not ready for 2006.\n<\/p>\n \n \nBut at least my pie looks good.\n<\/p>\n<\/p>\n Update<\/strong> (Nov 19): This article has inspired a great deal of discussion not only in the comments below but among other blogs. It seems people haev a lot to say about this subject! Many reactions point out that a single vector-based graphic is not likely to look great at all resolutions. Fine-tuning at the pixel level will remain a requirement. I hadn’t really considered this, but it makes a lot of sense. Ample payback for the time I spent writing this article!<\/p>\n \nSome of the most substantial reactions are linked to here:\n<\/p>\n \nSven-S. Porst<\/a> Resolution independence is the notion that all graphics on a computer display should be zoomable to an arbitrary multiplier without losing quality. If you know even the slightest thing about computer graphics, you’ll understand that in a resolution independent world, bitmaps are out and vector graphics are in. Vector graphics can scale gracefully to an […]<\/p>\n","protected":false},"author":10,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[14,31,11,15,19,5],"tags":[],"class_list":["post-223","post","type-post","status-publish","format-standard","hentry","category-apple","category-carbon","category-cocoa","category-programming","category-technology","category-xcode"],"_links":{"self":[{"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/posts\/223","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/comments?post=223"}],"version-history":[{"count":0,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/posts\/223\/revisions"}],"wp:attachment":[{"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/media?parent=223"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/categories?post=223"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/tags?post=223"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![](\"http:\/\/www.red-sweater.com\/blog\/images\/MarsEditZoomed.png\"\/)
\n<\/p>\n\n
![](\"http:\/\/www.red-sweater.com\/blog\/images\/QuartzDebugResolution.png\"\/)
\n<\/p>\n![](\"http:\/\/www.red-sweater.com\/blog\/images\/ScalingBitmapPie.jpg\"\/)
\n<\/p>\n![](\"http:\/\/www.red-sweater.com\/blog\/images\/ScalingVectorPie.jpg\"\/)
\n<\/p>\n![](\"http:\/\/www.red-sweater.com\/blog\/images\/ScalingLittleYellowGuy.jpg\"\/)
\n<\/p>\n![](\"http:\/\/www.red-sweater.com\/blog\/images\/ScalingToolbarButton.jpg\"\/)
\n<\/p>\n
\nJasper Hauser<\/a>
\nCraig Hockenberry<\/a>
\nChristopher Lloyd<\/a>
\nStephen Deken<\/a>
\nMarc Edwards<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"