| I use -drawRect any time I need a UIView's CGContext. For everything else, I use -layoutSubviews. When you do anything in Core Animation in -drawRect, that throws all drawing on CPU, instead of dividing the work between the CPU and GPU. Which, in one project where I was doing Core Animation alongside OpenGL, that had some very bad consequences. Core Animation is pretty interesting. Internally, it does some drawing with Core Graphics, but that's only if you use certain features (i.e., use of CAShapeLayers, anything involving shadows)... and even then, CG is pretty darned fast. I've found CAShapeLayers can be a bit of a resource hog, but since those resources tend to be thrown behind 60 fps animation, that might not be such a problem. The CAShapeLayer issues only came up when I tried scrolling within a scroll view that contained a CAShapeLayer with a CGPath that had 20 points defining lines. Setting the CAShapeLayer to -shouldRasterize:YES after the animation completed "fixed" the issue, as long as you didn't need to scroll while the CAShapeLayer was animating. (Don't even bother animating a CAShapeLayer while -shouldRasterize: is set to YES. That just causes even more fun problems with dropped frames.) |
Another note with -drawRect and animations, I messed around with CADisplayLink and -drawRect to make animations. Beware of doing this, it was a performance hog. It was a simple animation in a large rect, and by the time I had optimized the drawing area, I could have finished the entire project.
I wonder, would CAShapeLayer become more of a resource hog with more points in the path (or more complex arcs), or does it happen with the overall size of the path?