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

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.

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.

2 +1 for Opacity. – jbrennan Oct 22 '09 at 2:34.

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.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.