Core Animation Isn't Just for Animation
Often when I'm talking to somebody about how they're designing their app, I suggest they use Core Animation to implement the user interface. More times than I can count, I've gotten a puzzled look followed by the now-familiar "but I'm not really animating anything" response.Animation is the most significant obstacle that Core Animation tackles, but it's far from being the only benefit. This is a really versatile framework with huge performance potential. You can have thousands of CALayers on the screen at the same time without breaking a sweat. It probably wouldn't be practical to try the same with NSView instances.
There's a lot of GPU magic at play here. One element of it is the raw parallel processing power of modern graphics cards, and another is the fact that Core Animation can cache the contents of a CALayer on the card so that your code doesn't need to constantly redraw it. This, by the way, is part of the reason the iPhone UI is so incredibly fast on some relatively modest hardware. Core Animation can automatically take advantage of a multi-core Mac because the layer tree is rendered on a separate thread.
The framework also provides a vastly simplified graphics model. Instead of requiring a view to implement all of the logic to manage abstract "layer-like" objects that are composited onto the screen, Core Animation provides actual on-screen layers that do all of the basics for you. Creating a layer is as simple as:
- (void)createLayer
{
CGColorRef bgColor = CGColorCreateGenericGray ( 0.0, 0.25 );
CALayer* myLayer = [CALayer layer];
myLayer.bounds = CGRectMake(0,0,150,150);
myLayer.position = CGPointMake(20,20);
myLayer.backgroundColor = bgColor;
myLayer.borderWidth = 1.5;
[parentLayer addSublayer:myLayer];
CGColorRelease(bgColor);
}Once a layer is created, it's easy to customize its appearance and behavior with delegate callbacks. The delegate can draw a layer's contents or can trigger actions — such as animations — in response to events. CALayers can also accept values for arbitrary keys using standard key-value coding methods. All of this means a greatly-reduced need for custom CALayer subclasses.
Layout can either be done using NSView-like springs and struts, or by using the more sophisticated CAConstraintLayoutManager class, which sizes and positions layers relative to one-another based on per-layer rule sets.
Of course you also get all of the well-publicized features of Core Animation: easy-to-use animations, 3D space, filters and transitions, shadows, per-layer transforms, and so on, but don't underestimate the advantages of it in more casual settings.
Core Animation Isn't Just for Animation
Posted Oct 2, 2008 — 48 comments below
Posted Oct 2, 2008 — 48 comments below
Mike — Oct 02, 08 6424
Brian — Oct 02, 08 6425
You are are dead on about this. I was writing a user interface design and documentation application for tiger and the view layer of my code ended up being a poor version of core animation. When I first read about CA I was stunned, and I thought "this is about much more than animation". If I ever finish that project, it's going to be rewritten in CA.
Ryan Quattlebaum — Oct 02, 08 6426
Michael — Oct 02, 08 6427
Alexander — Oct 02, 08 6428
The two are not incompatible. Your tableview and movieview can both be layers.
Chuck — Oct 02, 08 6429
I think Scott is more suggesting layers to replace NSCells and custom drawing areas within views. For example, I have a sort of vector drawing app for Tiger -- it has one big "canvas" view that does all the drawing and hit-testing and so on for all the art objects stored in the model. I'd guess that vanilla CALayers could probably replace half the code in that canvas class.
ssp — Oct 02, 08 6430
Also: 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.
Obviously you want to avoid such sluggishness when doing UI work. Which somewhat restricts the useful areas of CA.
Lee Falin — Oct 02, 08 6431
Cocoa Newbie — Oct 02, 08 6432
Is there a downside to simply enable Core Animation on all views? OS X as well as Cocoa Touch?
Thanks, btw. I smile every time a new Theocacao post appears in my RSS feed. Cheers.
Scott Stevenson — Oct 02, 08 6434
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.
Roman Busyghin — Oct 03, 08 6436
I think usage of Core Animation adds a lot of complexity to my code or am I wrong?
Scott Stevenson — Oct 03, 08 6437
For Mac applications, Core Animation can be helpful if you're doing a lot of custom user interface elements. If you're mostly using the built-in views, there are fewer benefits.
On iPhone, it's probably better to use CALayers more liberally to reduce the need to redraw. Again, this isn't something I've compared closely between the platforms, but I remember this topic coming up at WWDC.
I think usage of Core Animation adds a lot of complexity to my code or am I wrong?
If you're creating a custom user interface, Core Animation can substantially simplify your code because it has built-in functionality for things you'd have to otherwise do yourself. It's designed to be easy to get started with, and works very much like other Cocoa frameworks.
But that's only if you've already decided to do custom UI. The simplest approach, of course, is to just use Cocoa's built in views.
Ben Barnett — Oct 03, 08 6438
This way, when you change the label for an axis (eg. from day of month to month of year), the lines and points can animate smoothly to their new positions. The hit testing is incredibly easy too, even for overlapping layers.
Martin Pilkington — Oct 03, 08 6439
Jeff Nichols — Oct 03, 08 6440
In my own Leopard only app I was super excited to use CoreAnimation to handle fading from view to view. But I just couldn't stand the way text was rendered and had to fall back to more 'traditional' methods for fading views. What a pity...
Jeff Nichols — Oct 03, 08 6442
David Vandevoorde — Oct 03, 08 6443
One biggie (for now at least), is that on iPhoneOS, Core Animation does not include filter-based animation.
On the other hand, Core Animation is more naturally integrated in Cocoa Touch than in MacOS X's Cocoa. E.g., view transitions can implicitly be animated (no need to change source to use a special property field).
Dan — Oct 03, 08 6445
Where did the name 'Theocacao' come from. Is it something I am not likely to know or am I just being incredibly thick today?
Paul Warren — Oct 03, 08 6447
I was using Cocoa Animation (core animation implemented in AppKit), initially layer-backed and was getting poor looking results with NSTableView (flickering contents on resize etc. possibly because of the NSScrollView performance hit, Scott mentions above), I switched off the WantsLayer but left the view animator code and got exactly what I needed and it works perfectly. I assume this is the "animation" code in AppKit that doesn’t require CAlayers.
Appkit animation and Layer-Backed animation seemed to coexist nicely within the window providing that the AppKit view doesn't inherit the Layer property from the view hierarchy.
Harvey — Oct 03, 08 6448
Scott Stevenson — Oct 03, 08 6454
That's true in general and it's a good point to make. That said, I've found that using floor() to filter the x and y values of the layer's "position" property can produce vastly better text rendering results.
@Paul Warren: initially layer-backed and was getting poor looking results with NSTableView (flickering contents on resize etc
It shouldn't do that. It might be a bug, but I'd have to see the code to say for sure. One thing that can cause this is mixing layer-backed views and standard views in non-ideal ways.
@Harvey: One reason not to use Core Animation is the lack of any Accessibility support.
Accessibility is an important topic, but I think it's (unintentionally) misleading to say that Core Animation lacks accessibility support.
It's true that a built-in view like NSTableView or NSTextView has accessibility support that a custom view built from CALayers does not, but it's mostly the same for a custom view whose entire contents is drawn directly into a graphics context. I think this is really more about implementing accessibility support in custom views in general.
You can add accessibility support to Core Animation-based user interfaces, and there was actually an entire session about this exact topic at WWDC 2007. I don't remember offhand if there was one at WWDC 2008.
@Dan: This is completely off topic, but I have been pondering it for a while. Where did the name 'Theocacao' come from
It's basically a contraction of "Theobroma Cacao". I thought it was sort of clever at the time. In retrospect, it's fairly hard to pronounce.
Harvey — Oct 04, 08 6455
Mark Buckingham — Oct 04, 08 6456
Charles Parnot — Oct 04, 08 6458
WantsLayer is needed for things other than moving the frame/bounds around, for instance for fading views,... If you are just moving views arounds, the animator works without the need for WantsLayer (and then none of the text rendering issues).
Chuck — Oct 05, 08 6459
The problems you're blaming on Core Animation are just a problem of custom interfaces in general. If you're doing a custom interface, Core Animation isn't going to make accessibility any more work than, say, using NSCells and a custom view class that draws them in place.
It's like saying, "Well, the problem with using Core Animation on the iPhone is that if you're using Core Animation, it will limit your app to 128 MB of RAM." The 128 MB limit is inherent in the iPhone -- it's not something that's wrong with Core Animation. Similarly, lack of accessibility is inherent in custom interfaces -- it's not something that's wrong with Core Animation.
ssp — Oct 05, 08 6460
As I said, CA stuff seemed sluggish compared to direct NSView drawing.
I'd link to a blog post I wrote on the topic, but it seems I forgot to publish it… will do that in the coming days.
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.
I haven't seen that 'live' myself, but I'd say it's exactly a usage case which is not interactive and where latency or snappiness doesn't play a role.
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.
That's why I asked about numbers or concrete experiences. It's unsurprising that _on paper_ Apple make their technologies sound great. And I am not even speaking about filters or computationally expensive stuff here. All I tried to do was to use CA for superimposing a handful of elements I needed drawn in my view – no filters used at all.
Scott Stevenson — Oct 05, 08 6463
Core Animation layers have no depth. It's famously called "2D planes in space," which means the environment is 3D, but the layers themselves aren't. OpenGL is full 3D, and a far more flexible API in general. Of course, the tradeoff is that Core Animation is much easier to learn and is directly integrated with Cocoa.
@ssp: I haven't seen that 'live' myself, but I'd say it's exactly a usage case which is not interactive and where latency or snappiness doesn't play a role.
The scene is thousands of album covers flying around in 3D space at a smooth framerate. It's a fairly complex scene requiring a lot of horsepower.
That's why I asked about numbers or concrete experiences.
You could download the NanoLife sample I posted and increase the layer count to 200 or more. I think you'll be impressed with the performance. If not, than it's possible the rendering isn't happening on the graphics card for some reason (something below Cocoa).
It's unsurprising that _on paper_ Apple make their technologies sound great
This is definitely not a case where the technology is just good on paper. Core Animation has astounding real-world performance, which is well-demonstrated on iPhone. That said, like any API, it's easy to undermine the performance in a single line of code by calling the wrong thing at the wrong time.
All I tried to do was to use CA for superimposing a handful of elements I needed drawn in my view
That's well within the intended uses cases for the API. Feel free to email me the code if you want me to take a glance. Core Animation performance should not just be "decent" but blisteringly fast. The only qualification to that is that filters can be quite slow when animated.
Mark Buckingham — Oct 05, 08 6464
Core Animation layers have no depth. It's famously called "2D planes in space," which means the environment is 3D, but the layers themselves aren't. OpenGL is full 3D, and a far more flexible API in general. Of course, the tradeoff is that Core Animation is much easier to learn and is directly integrated with Cocoa.
So... Would it be fair to say that if you're doing a 2D game like galaga, then Core Animation might work well, but not if you're trying for a 3D game? I actually like 2D games, so that might be good news. :-)
Scott Stevenson — Oct 06, 08 6465
I can't think of any reason offhand it wouldn't work. OpenGL is the most common choice, and would probably perform better (as it's a lower-level API), but Core Animation may allow you to write the game much more quickly than with raw OpenGL. This doesn't take into account pre-built game engines that use OpenGL, of course.
But, essentially, yes. It should work for 2D games, or even games with 2D objects in 3D space -- along the lines of paper Mario. Core Animation can also natively accept Quartz Composer and QuickTime content (or even video from the iSight), which may be an advantage.
I think you should also be able to take a hybrid approach, mixing Core Animation with OpenGL content. This is outside of my area of knowledge, though, so I'm not sure what the details are.
ssp — Oct 07, 08 6467
I found my blog post on CA again and published it at the link I gave with my name.
It should describe the problems I was seeing with responsiveness in more detail. As I said before this is not about the number of layers but rather about latency which seems to be a bit bigger with CA than with direct drawing.
As I said before, I don't doubt that CA can wiggle big numbers of pixels around. I just said that I didn't find it better than direct NSView drawing when interaction comes into play. UI wise I consider the cases with direct interaction to be the important ones as pretty flying animations and screensavers aren't what makes a computer useful to most people.
Rodolfo Niborski — Oct 08, 08 6470
I'm an amateur programmer, and quite new to CA. I found the topic and comments interesting and the NanoLife example quite impressive.
But when trying to do some animation myself, I couldn't manage to animate the foreground color of a letter in a CATextLayer. Is the framework in some sense incomplete or am I missing something ?
Gabriele de Simone — Oct 08, 08 6471
In plain English, text rendered in a CA-backed layer will not look the same (as sharp, good-looking) as any other non-CA text on screen (e.g. the menubar). This can be ugly if you have parts of your window that are CA-backed and parts that are not.
I would hate to be wrong about this, if there's any way of turning on the higher-quality text anti-aliasing algo for CA-backed layers, let me know :-)
Chuck — Oct 08, 08 6472
You're right that Core Animation doesn't have subpixel antialiasing (and it's a shame), but actually, the menubar uses the same antialiasing that Core Animation uses. Zoom in and see for yourself. I guess the difference is not necessarily all that noticeable sometimes.
Brad Larson — Oct 08, 08 6473
If I remember correctly (from what one of the engineers told me at WWDC), sub-pixel antialiasing requires there be a known background behind the text. For a layer-backed view, you need to set the background to an opaque color and have the view draw the background. A CATextLayer is a little more complicated, but it's the same idea.
See this message for more specific information.
Michael — Oct 12, 08 6483
Hey, thanks for the article. It came right in time for me -- I'm developing an app that needs to display dozens of small custom-ui elements in a special view, and CA sounds like a good fit.
One obstacle comes to my mind though -- in my ui elements I'll display text, which needs to be selectable (not editable though). In my current implementation I'm using NSCell for drawing this text + NSCell field-editor-alike functionality for providing the selection mechanism. That works perfect.
Not sure how I would do that with CALayer... without having the field editor draw over the layer-backed view etc. which sounds a little bit messy.
Scott Stevenson — Oct 13, 08 6485
There are any number of ways to get text onto the screen, so what you describe shouldn't be an issue. For example, you can just use a CATextLayer to display text, and then maybe add a text field as a subview when you want to edit something. I haven't done this exact thing in Core Animation so there might be a more proven way.
Personally, I think you should rarely have to deal with NSCells directly, other than when using tables or other multi-part views. In general, I think Cocoa apps will mostly be dealing with views and layers from here on out. That's just my perception, though.
Michael — Oct 14, 08 6490
Ie. the NSAttributedString boundingRectWithSize:options: is way slower since it doesn't cache any data and regenerates the glyphs every time it's called.
LuisV — Oct 17, 08 6497
Thanks.
Scott Stevenson — Oct 17, 08 6499
Hi Luis, it's been really challenging to keep the tutorials in sync with newer versions of Xcode. I've already updated Learn Cocoa Part 1 three times, for example. It typically takes two-to-three full days of work for me to do a new revision.
There's also a balanace to strike between writing new tutorials (like the recent Objective-C intro) and updating older tutorials. I'll do the best I can to update Learn Cocoa Part 2 as soon as possible.
Steven Degutis — Oct 19, 08 6502
Although I haven't actually tried it out yet and seen for myself if this works as well as you said, it's definitely worth looking into, because I've had the performance hit you're talking about in one of my applications, and this really looks like a clever solution. Thanks!
Steven Degutis — Oct 19, 08 6503
I've taken your advice on this post, however probably a little unconventionally. I'm writing a small utility that is a graphical wrapper for class-dump, and it sits in the menu bar as an NSStatusItem most of the time, yet it isn't entirely obvious the first time where the application is. So, the conclusion I've come to with the help of some friends, is that a quick splash screen would help to explain where the application is. Using MAAttachedWindow for this window, I can bring out the splash screen for a second or two, and then have it animate fancily right into the status item itself, perhaps even using a "genie effect".
neuro — Oct 21, 08 6506
and now with all the mac books line supplied with GPU's , core animation is the way to go . right?
Scott Stevenson — Oct 22, 08 6509
That's the basic idea, yep.
Sherwin Zadeh — Oct 31, 08 6514
Alex Reynolds — Nov 02, 08 6515
To move it up one row, I clip 320x479 pixels from the existing UIView and draw the next 320x1 row. Its performance is okay.
Would CALayers work better? Is there a good demonstration app or sample code for using CALayer objects with the iPhone SDK?
Scott Stevenson — Nov 02, 08 6516
I think I'd have to see the app to get a better overall feel for it, but I believe CALayers are generally preferred on the phone for performance reasons. As for samples, I think there are quite a few that use CALayer, but I don't know of a link to any of them offhand.
lakshmivyas — Apr 23, 09 6718
Excellent article and I admire your well reasoned responses to comments.
That said, I've found that using floor() to filter the x and y values of the layer's "position" property can produce vastly better text rendering results.
What if the layers are laid out using CAConstraintLayoutManager? Is it better for text rendering layers to use custom layout managers so that the position can be fixed?
Flurry — Feb 26, 10 7756