More. Power.

One challenge of developing a graphically rich application is making sure the animation is as quick and fluent as possible. The iPhone doesn’t have the horse power of a MacBook Pro, so every detail matters when working with animating many things at once. There are two ways to get pictures onto the screen, using quartz or UIKit core animation through subviews. Each way impacts how smoothly an animation can occur.

Using Subviews to draw

For an application like Album Shuffle, each album you see on screen is comprised of two images: the actual album artwork and a shadow/gloss image that I created in Photoshop. So to draw each album using subviews, each album would be a base UIView with two UIImageViews as a subviews. Rotating this view creates terrible pixelation, but even more importantly is that every time an album is move across the screen, three views are moved. That means the GPU has to work at calculating the image movements three times over. All of this is compounded by the fact that there is transparency because of the shadow the album creates. As a result, the frame rate drops too low to practically use.

Using Quarts to draw

To illustrate the difference between Core Animation and Quartz, think of the iphone screen like a photoshop document. You have a bunch of layers, and when you move these layers all together, each layer individually moves to a different point. Thats core animation. Quartz is more like flattening all these layers into one layer and then moving it.
Quartz becomes a very practical solution for Album Shuffle. An album graphic is initially drawn to a UIView, and never needs to be redrawn because the graphic never changes. (A rotation and translation of the album is handled by the UIView.) Transparency is still a bottleneck, but by eliminating the overhead created by using subviews, the frame rate goes up dramatically.

Applying drawing to UITableviews

Table Views present a similar problem to the Album Shuffle app. If you were to create cells using UILabels and UIImageViews, you could be faced with animating around twelve cells at a time with transparent subviews. (Why 12? Table Views don’t draw cells outside the screen, instead it uses cells that are moved off the screen for cells of the ones moved into the screen). This creates a lot of work for the processor to animate all these subviews, and it eventually can’t keep up with the scrolling, and as a result, the motion gets jerky. The solution is to use Quartz to draw the cell graphic so each cell is one flat view with no transparency (transparency slows the GPU down). Each time a new cell is moved on the screen, the whole cell must be redrawn, but this process doesn’t bog the iPhone enough from animating everything smoothly.

For more information on faster tableview scrolling, atebits has create a helpful subclass of UITableView to get faster scrolling. Apple’s >TableViewSuite demo’s fifth example goes over this same technique. For more info on drawing with Quartz, look at Apple’s QuartzDemo. When working with animation and frame rates, make sure to test on an actual iphone device and not the simulator. The simulator won’t give you an accurate measure of how smoothly the application runs because the simulator doesn’t emulate the speed of the iPhone.