In the previous part I gave a quick introduction to resolution independence. This part explains what technical limitations exist that complicate the job of creating high quality resolution independent icons.
The Raster Approach
With raster graphics (or bitmap graphics) an image is basically described as a grid of pixels, where each pixel has a different color value. Though a raster graphic can be rendered quickly, it cannot be scaled up or down without any quality loss as a grid of independent pixels does not contain any comprehensive information about the scaled subject.
To overcome the quality loss problem in the context of icon design it is common practice to provide one separate raster graphic instance for each size the icon may be rendered at. Typically these different icon versions are collected together in one umbrella file format such as .ICO (on the Windows platform) or .ICNS (on the Mac platform). The application programmer has to decide which version of the icon should be rendered under which circumstances.
Back in Windows XP times (well not way back, as it still enjoys great popularity) a usual .ICO file contained different icon versions at 16 x 16, 32 x 32 and 48 x 48 pixels (sometimes also 24 x 24 pixels). At this time Mac OS X Tiger already supported sizes up to 128×128 pixels, collected in an .ICNS file. To address the problem with high ppi devices, Windows Vista’s .ICO format was extended to support an additional 256 x 256 pixel icon version.
As if this wasn’t enough, Apple recently introduced giant 512 x 512 pixel icons in Mac OS X Leopard (e.g. to be used by Front Row) and explains their necessity with resolution independence. This kind of arms race shows the problem with the pure raster image approach: it just does not scale well.
A 512 x 512 pixel icon takes almost 800 KB in main memory and even when compressed it may have a considerable size. In times of Rich Internet Applications (RIAs) where everything is deployed via the network this is something to be kept in mind. I am over-exaggerating a bit here as these huge sizes are mainly necessary for desktop icons that need to brand a product. At least for now the gross amount of icons shown inside an application remain smaller than 64 x 64 pixels. However, though we don’t face a problem at the moment, we will face it in the future. The higher pixel densities grow the larger even non-application icons have to get. If an application contains hundreds of icons and each icon is provided at large sizes, memory consumption becomes a significant factor – particularly in the Rich Internet Application context.
The Vector Approach
Vectors are a common means to produce images that can be scaled to different sizes without any quality loss. Hence, in an ideal world, we would just create our icons in an image-editing tool that supports vector graphics (such as Photoshop, Illustrator or Inkscape) and export them to a well-known vector format such as SVG, PDF, XAML or (the little bit less known) JavaFX Script, which in turn can be directly loaded and rendered in our application.
Slow Rendering Performance
The first problem however is that vector-based graphics take a considerable amount of time to render on-the-fly (i.e. to convert vector data into pixel information each time the graphic is painted on the screen). So why is it possible in modern computer games to render super-realistic three dimensional scenes with dynamic light and shadow effects and smooth animations in real-time when it is painfully slow to render a vector-based icon that just uses two dimensions, is not animated and has its light and shadow effects already set in stone? Well, modern games make heavy and exclusive use of what the graphics hardware offers while most applications are based on top of software frameworks that have to deal with abstraction and compatibility issues and need to share the graphics hardware with others of their kind without being able to directly access the graphics hardware’s full capabilities. The details are of course more complex, but I don’t want to get off topic here. The essence however is: rendering vector-based icons on-the-fly could be amazingly fast in theory but is annoyingly slow in practice – still too slow to be a feasible option at the moment.
Poor Export of Vector Data
The second problem is that the export functionality of most state-of-the art vector-based tools is quite poor. Popular icon effects such as drop shadows or glows for example will still be rasterized during export, resulting in large target files that take a long time to load, consume a large amount of memory and – what’s most annoying – contain a fair amount of graphics that are still not vector-based. That means when exporting an icon you actually end up with a bulky PDF, SVG or XAML file that is supposed to be scalable infinitely without any quality loss, but isn’t as it contains raster information. Neither a novel application such as Microsoft® Expression® Blend committing itself to resolution independent UIs nor an old stager such as Adobe® Illustrator get around raster graphics entirely when it comes to sophisticated visual effects. As to Illustrator, the new JavaFX export plugin (currently codenamed as project Nile) looks promising as it does not rasterize shadow effects during export. However, the project is in its early stages and still suffers from many teething problems.
The Vector Rasterization Dilemma
Finally, a problem that almost eclipses the other two is that a single vector-based description of an icon can never produce crisp, pristine and aesthetic results at all sizes the icon is being rendered: either you have a low-detail vector icon that looks nice for small sizes but looks dull when rendered at large sizes or you have a high-detail vector icon that looks amazing in huge sizes but looks like a piece of pixel junk when rendered at smaller sizes.
In the next part I will describe how we deal with this limitation at Centigrade to effectively create high quality icons for different sizes.