So, does CALayer not contain bitmap content?

Question

From the docs:

"Layers are light objects (CALayer), which, although similar to representations, are actually model objects assigned to representations."

Easy for me eliminates any heavy bitmap for content. I figured CALayer is the "real" thing, and UIView is just a wrapper around it. Each view has 3 CALayers in different trees (model, presentation, rendering). So, no 3 bitmaps? Only one?

Answer 1

The term "light weight" as applied to CALayer comes from this part of the documentation created on the Mac. As Joe points out, NSView is a pretty sophisticated user interface element compared to the iPhone UIView. You can animate dozens of UIViews across the screen even on a mobile device with limited resources, but NSViews put a lot more strain on the system when you start adding many of them to the screen. This is one of the things that the new UIKit launch over AppKit got, because UIKit had Core Animation from the very beginning, and Apple had a chance to find out what worked and what didn’t in AppKit.

In comparison, CALayer adds very little to the base raster texture based on the GPU it draws, so they don't add a lot of overhead. On the iPhone, this is not much different from UIView, because UIView is just a lightweight wrapper around CALayer.

I'm going to disagree with Count Chokula on this and say that CALayer seems to complete the raster texture on the GPU. Yes, you can specify a custom Quartz drawing to compose the contents of the layer, but this drawing will take place when necessary. After the content in the layer is drawn, it does not need to be redrawn for the layer that needs to be moved or otherwise animated. If you apply the transformation to the layer, you will see that it becomes uneven when you zoom in, a sign that it does not deal with vector graphics.

In addition, with the Core Plot base (and in my own applications), we had to redefine the normal CALayers drawing process, because the normal approach -renderInContext: did not work well for PDF files. If you use this to render a layer and its sublayers in a PDF, you will find that the layers are represented by bitmap bitmaps in the final PDF file, not by the vector elements that they should be. Only using a different rendering path, we were able to get the correct output for our PDF files.

I still need to play with the new shouldRasterize and rasterizationScale properties in iOS 3.2 to see if they change the way they are handled.

In fact, you will find that CALayers (and UIViews with their background layers) consume a lot of memory when you consider their bitmap content. An “easy” measure is how much they add over the content, which is very small. You may not see memory usage from a tool like Object Allocations, but look at Memory Monitor when you add large layers to your application and you will see memory spikes in your application or SpringBoard (which owns the Core Animation server).

When it comes to the presentation and model layer, the bitmap is not duplicated between them. At the moment, only one raster texture should be displayed on the screen. Different layers simply track properties and animations at any given time, so very little information is stored in each record.

Answer 2

As I understand it, CALayer is an image of a quartz surface. You cannot think about it in terms of bitmap images, but rather a container that encapsulates the current state of the drawing context, including its contents, transformation, shadows, etc. It’s basically as close as you can get to the GPU while staying within Cocoa, but it’s not the same as the presentation of a bitmap — rather, it presents all the information needed to reproduce its contents as you do it instruct. So, for example, if you draw a line on it, the layer inside could just pass the line coordinates to the GPU and let the latter draw it without worrying about the pixels needed for rendering.

Compared to UIView, a layer is “light” in the sense that it only deals with display operations and is not related to things, such as responses to events or touches, etc.

The reason for the presence of both the model and the presentation level is that the latter represents the current state of the level, while preserving all the animations. This is why, for example, the documentation recommends that you click testing at the presentation level.