When programming for the iPhone, when is it best to use CoreAnimation over another API (and vice-versa)? OpenGL has a more generic range of features (being as low-level as it is). CoreAnimation is a lot easier to get set up, and it has features like caching.
I’m making a game (2D), and it involves a lot of physics. I really want this game to run at a minimum of 50 FPS, preferably 60 (or whatever is necessary to keep up with vsync). I don’t know how to utilize animations in this case, but I can split everything up into sprites/CALayers. I’ll be setting their position and rotation every frame (maybe just the visible ones). Many of the sprites are identical. Some of these sprites will be changing colors every frame. I won’t be using many images, but I will be using a lot of gradients.
So, will CoreAnimation be an optimization or a bottleneck? When is it best to use CoreAnimation, and when is it best to use other APIs?
Core Animation lets you do a lot with a minimal amount of code. It makes managing 2-D layers and their animation relatively easy. Because animations are handled for you, even those involving complex paths or timing curves, you don’t need to write code to update the display every frame or calculate the tweening of an animation. Core Animation also integrates nicely with the 2-D drawing capabilities you have in Quartz, with native Cocoa Touch interface elements and touch handling, and with your Objective-C code elsewhere in your application.
If you use the framework as intended, you can achieve very good performance. In my benchmarks on my old first-generation iPhone, I was able to animate 50 translucent layers at once onscreen at about 60 FPS. However, this is with predefined linear paths being specified for each layer ahead of time and no interruption of the animations.
OpenGL ES is for when you just don’t think you’ll be able to get the necessary performance without talking directly to the underlying hardware, or for when you need to do true 3-D work (Core Animation can do limited 3-D effects, but only with rectangular planes). The tradeoff for having better performance and more flexibility is the need to write a lot more code that is a lot harder to read. Also, it can be a nightmare to debug OpenGL ES sometimes.
One other potential advantage of OpenGL ES is that it is pretty platform-independent, so you might be able to build your renderer in such a way that it can easily be transplanted from iPhone to Android, the desktop, etc.
In general, my recommendation has been to look to Core Animation first to see if it can do what you want, because you’ll be able to build an application much faster this way. If that’s not appropriate, and you’re looking at doing a 2-D game, perhaps cocos2d would be a good path. I’ve not used the framework myself, but I’ve heard that it simplifies the process of doing 2-D OpenGL ES work. Only if neither of these approaches are appropriate should you drop down to OpenGL ES.
If you’re curious, I do cover both Core Animation and OpenGL ES in the videos for my course on iTunes U, where you can skim through and see what’s needed to work in either environment.