@Michael: Are you suggesting using CALayers instead of NSViews?
Layers are not a complete replacement for views, but they are better in many cases where before you either had to use regular subviews or "virtual subviews" (basically data structures that act like layers).
There will almost always be at least one top-level view, though, which can host one parent layer and any number of sublayers.
What if I want to create a panel with two subviews, a tableview and another view containing a QTMovieView for instance. How could I do that by only using CALayer?
That's a more simple case and I'm not sure you'd see any real advantage in making those both pure CALayers. I think you'd be much better off with simply making both of those views layer-backed (I think this is what Alexander was referring to). You'd get the fancy effects and content caching of CALayers with the high-level event conveniences of NSView.
@Chuck: it has one big "canvas" view that does all the drawing and hit-testing [...] CALayers could probably replace half the code in that canvas class
That sounds like a pretty good example, yes.
@ssp: In how many real world applications will you really 'thousands of CALayers' along with all the extra flexibility they provide?
It's a fair question, and my original statement was really just intended to highlight the ability to offload a lot of the work to the graphics card. But even putting theoretical layer count aside for a moment, the content caching, background rendering, and compositing features are more than enough reason on their own.
Now, bringing the layer count back into the picture, consider something like a web browser rendering engine. Each of the elements on page have to be represented by some sort of data structure. There are far too many elements for each to be a separate view, so they're often defined by abstract, lightweight data structures.
With Core Animation, you might be able to tackle something like that with CALayers instead. Now, a web browser engine isn't a great example overall for a number of reasons, but it does have to deal with very large numbers of individual elements. iPhoto would be another good example of a large number of individual items that have to be drawn in a larger canvas.
can you put numbers behind your claim of CA's great performance? My attempts to draw things using CALayers always ended up feeling sluggish compared to directly drawing my NSView
I'd be interested in what specific things you've seen. From a computation perspective, Core Animation has vast ocean of raw power at its disposal in the graphics card. The most obvious example of this is the "iTunes album art city" screensaver that bounced around WWDC and the Leopard promotion site. There would be no hope of recreating that with conventional NSViews.
So on paper at least, there really should be no contest in terms of raw performance between equivalent NSViews and CALayers. That said, some of the special effects (filters, for example) are very expensive — I assume because they don't all happen on the graphics card. So if you're using bloom filters and such, then things can get sluggish.
@Cocoa Newbie: What are the differences between Core Animation on Mac OS X and Cocoa Touch?
I haven't looked at this closely so I don't have a definitive answer. My general understanding is that the differences are minimal.
Is there a downside to simply enable Core Animation on all views? OS X as well as Cocoa Touch?
The main limitation of layer-backed views is that they are restricted by the maximum OpenGL texture size, which I believe is typically 2048x2048. If you have a layer or a layer-backed view which is larger than that, then you need to switch to CATiledLayer instead of the generic CALayer. I believe this is what layer-backed NSScrollViews use, for example.
From what I remember, CATiledLayer has some limitations, such as not supporting Core Image-backed transitions.
I smile every time a new Theocacao post appears in my RSS feed. Cheers.
by Scott Stevenson — Oct 02
Layers are not a complete replacement for views, but they are better in many cases where before you either had to use regular subviews or "virtual subviews" (basically data structures that act like layers).
There will almost always be at least one top-level view, though, which can host one parent layer and any number of sublayers.
What if I want to create a panel with two subviews, a tableview and another view containing a QTMovieView for instance. How could I do that by only using CALayer?
That's a more simple case and I'm not sure you'd see any real advantage in making those both pure CALayers. I think you'd be much better off with simply making both of those views layer-backed (I think this is what Alexander was referring to). You'd get the fancy effects and content caching of CALayers with the high-level event conveniences of NSView.
@Chuck: it has one big "canvas" view that does all the drawing and hit-testing [...] CALayers could probably replace half the code in that canvas class
That sounds like a pretty good example, yes.
@ssp: In how many real world applications will you really 'thousands of CALayers' along with all the extra flexibility they provide?
It's a fair question, and my original statement was really just intended to highlight the ability to offload a lot of the work to the graphics card. But even putting theoretical layer count aside for a moment, the content caching, background rendering, and compositing features are more than enough reason on their own.
Now, bringing the layer count back into the picture, consider something like a web browser rendering engine. Each of the elements on page have to be represented by some sort of data structure. There are far too many elements for each to be a separate view, so they're often defined by abstract, lightweight data structures.
With Core Animation, you might be able to tackle something like that with CALayers instead. Now, a web browser engine isn't a great example overall for a number of reasons, but it does have to deal with very large numbers of individual elements. iPhoto would be another good example of a large number of individual items that have to be drawn in a larger canvas.
can you put numbers behind your claim of CA's great performance? My attempts to draw things using CALayers always ended up feeling sluggish compared to directly drawing my NSView
I'd be interested in what specific things you've seen. From a computation perspective, Core Animation has vast ocean of raw power at its disposal in the graphics card. The most obvious example of this is the "iTunes album art city" screensaver that bounced around WWDC and the Leopard promotion site. There would be no hope of recreating that with conventional NSViews.
So on paper at least, there really should be no contest in terms of raw performance between equivalent NSViews and CALayers. That said, some of the special effects (filters, for example) are very expensive — I assume because they don't all happen on the graphics card. So if you're using bloom filters and such, then things can get sluggish.
@Cocoa Newbie: What are the differences between Core Animation on Mac OS X and Cocoa Touch?
I haven't looked at this closely so I don't have a definitive answer. My general understanding is that the differences are minimal.
Is there a downside to simply enable Core Animation on all views? OS X as well as Cocoa Touch?
The main limitation of layer-backed views is that they are restricted by the maximum OpenGL texture size, which I believe is typically 2048x2048. If you have a layer or a layer-backed view which is larger than that, then you need to switch to CATiledLayer instead of the generic CALayer. I believe this is what layer-backed NSScrollViews use, for example.
From what I remember, CATiledLayer has some limitations, such as not supporting Core Image-backed transitions.
I smile every time a new Theocacao post appears in my RSS feed. Cheers.
That's very kind. Thank you.