Question

From the docs:

“Layers are lightweight objects
(CALayer) that, though similar to
views, are actually model objects
assigned to views.”

Lightweight for me excludes any heavy bitmap for content. I believed a CALayer is the “real” thing, while a UIView is just the wrapper around it. Every view has 3 CALayers in different trees (model, presentation, render). So no 3 bitmaps? Only one?

Answer 1

The term “lightweight” in reference to a CALayer comes from that piece of documentation originating on the Mac. As Joe points out, an NSView is a fairly complex UI element when compared to the iPhone’s UIView. You can animate dozens of UIViews around the screen on even a resource-constrained mobile device, but NSViews put a lot more strain on the system as you start adding many of them to the screen. This is one of the things gained by the fresh start of UIKit over AppKit, because UIKit has had Core Animation from the beginning, and Apple had a chance to learn from what worked and what didn’t in AppKit.

In comparison, a CALayer adds very little to the underlying GPU-based bitmapped rectangular texture that it is drawing, so they don’t add a lot of overhead. On an iPhone, this isn’t very different from a UIView, because a UIView is then just a lightweight wrapper around a CALayer.

I’m going to disagree with Count Chocula on this, and say that a CALayer does appear to wrap a bitmapped texture on the GPU. Yes, you can specify custom Quartz drawing to make up the layer’s content, but that drawing only takes place when necessary. Once the content in a layer is drawn, it does not need to be redrawn for the layer to be moved or otherwise animated around. If you apply a transform to a layer, you’ll see it get pixelated as you zoom in, a sign that it is not dealing with vector graphics.

Additionally, with the Core Plot framework (and in my own applications), we had to override the normal drawing process of CALayers because the normal -renderInContext: approach did not work well for PDFs. If you use this to render a layer and its sublayers into a PDF, you’ll find that the layers are represented by raster bitmaps in the final PDF, not the vector elements they should be. Only by using a different rendering path were we able to get the right output for our PDFs.

I’ve yet to play with the new shouldRasterize and rasterizationScale properties in iOS 3.2 to see if they change the way this is handled.

In fact, you’ll find that CALayers (and UIViews with their backing layers) do consume a lot of memory when you take their bitmapped contents into account. The “lightweight” measure is how much they add on top of the contents, which is very little. You might not see the memory usage from an instrument like Object Allocations, but look at Memory Monitor when you add large layers to your application and you’ll see memory spikes in either your application or SpringBoard (which owns the Core Animation server).

When it comes to the presentation layer vs. the model one, the bitmap is not duplicated between them. There should only be the one bitmapped texture being displayed to the screen at a given moment. The different layers merely track the properties and animations at any given moment, so very little information is stored in each.