iPhone Performance Differences in Quartz Drawing vs. Pre-Baked Images (which I guess simplifies to Quartz vs. Quartz)

Question

New to Quartz and I am curious on the drawing speeds of simple shapes, gradients, and shadows; specifically comparing Quartz drawing functions to Quartz image drawing on the iPhone.

Say that I need to draw a filled, stroked, and shadowed rectangle. I'm assuming that importing a pre-baked rect as a PNG and drawing it using drawInRect: or drawAtPoint: is faster than using Quartz's drawing functions to draw the same thing, since the latter requires explicit calculations. On the other hand, drawing an image I assume increases memory use and application size since I have to import the image and then alloc it. Does this sound right?

Besides that, are there any big advantages/disadvantages to either technique? As someone who is very familiar with graphics programs and brand new to Quartz, I'm trying to decide if there are any advantages to using the drawing functions in my code as opposed to pre-baking the entire UI and importing the images.

Answer 1

I had a similar question, so I timed out the different approaches. In most simple drawing cases (like your rectangle example), loading an image from disk seemed to be slightly slower than drawing one, perhaps due to the disk access required. In those cases, I've settled on using the Quartz drawing routines, simply because of the flexibility they give me. If I want to change the size of a UI element in the future (maybe to support a larger or higher resolution display), I would need to re-render all of my images, where the vector drawings will scale as needed.

One area where I did see a significant performance win is for a large radial gradient that I draw as a background. In Shark, I could see that the CGContextDrawRadialGradient() call was chewing up a lot of CPU time. When I replaced the Quartz-drawn radial gradient with a static image, I saw a noticeable reduction in application startup time (this background is placed during application startup). Oddly, I also saw a reduction in application memory usage by about 0.5 MB, which I can't fully explain.

If you want to test this yourself, I highly recommend picking up the image editor Opacity, which can generate Quartz code for a drawing (including a full UIView or CALayer subclass), as well as output a PNG of that same drawing. This makes it trivial to implement both paths within your application and test them out.

Answer 2

There's also a middle ground that might work, depending on your application structure: implement the drawing code, but draw into a layer, and then reuse it. This has the advantage of not chewing up CPU time more than once, but still keeping the drawing process dynamic.

So, say, when The Tablet finally ships (any day now!!), you can rework your drawing parameters a little to cover all possible devices, rather than generating a bunch of different static images.