CALayer vs CGContext, which is a better design approach?

Question

I have been doing some experimenting with iOS drawing. To do a practical exercise I wrote a BarChart component. The following is the class diagram (well, I wasnt allowed to upload images) so let me write it in words. I have a NGBarChartView which inherits from UIView has 2 protocols NGBarChartViewDataSource and NGBarChartViewDelegate. And the code is at https://github.com/mraghuram/NELGPieChart/blob/master/NELGPieChart/NGBarChartView.m

To draw the barChart, I have created each barChart as a different CAShapeLayer. The reason I did this is two fold, first I could just create a UIBezierPath and attach that to a CAShapeLayer object and two, I can easily track if a barItem is touched or not by using [Layer hitTest] method. The component works pretty well. However, I am not comfortable with the approach I have taken to draw the barCharts. Hence this note. I need expert opinion on the following

1. By using the CAShapeLayer and creating BarItems I am really not using the UIGraphicsContext, is this a good design?
2. My approach will create several CALayers inside a UIView. Is there a limit, based on performance, to the number of CALayers you can create in a UIView.
3. If a good alternative is to use CGContext* methods then, whats the right way to identify if a particular path has been touched
4. From an Animation point of view, such as the Bar blinking when you tap on it, is the Layer design better or the CGContext design better.

Help is very much appreciated. BTW, you are free to look at my code and comment. I will gladly accept any suggestions to improve.

Best, Murali

Sustentation

the only way to really know is to try both and profile your performance.. but as @eonil suggested, I would start with CALayer, using CAShapeLayer for any rendering of CGPath's. I'd bet money that that's the fastest, except in very limited circumstances. If you do find you are hitting performance problems, you can also try resorting to CATiledLayer. – Sebbie

Answer 1

IMO, generally, any kind of drawing shapes needs heavy processing power. And compositing cached bitmap with GPU is very cheap than drawing all of them again. So in many cases, we caches all drawings into a bitmap, and in iOS, CALayer is in charge of that.

Anyway, if your bitmaps exceed video memory limit, Quartz cannot composite all layers at once. Consequently, Quartz have to draw single frame over multiple phases. And this needs reloading some textures into GPU. This can impact on performance. I am not sure on this because iPhone VRAM is known to be integrated with system RAM. Anyway it's still true that it needs more work on even that case. If even system memory becomes insufficient, system can purge existing bitmap and ask to redraw them later.

1. CAShapeLayer will do all of CGContext(I believe you meant this) works instead of you. You can do that yourself if you felt needs of more lower level optimization.

2. Yes. Obviously, everything has limit by performance view. If you're using hundreds of layers with large alpha-blended graphics, it'll cause performance problem. Anyway, generally, it doesn't happen because layer composition is accelerated by GPU. If your graph lines are not so many, and they're basically opaque, you'll be fine.

3. All you have to know is once graphics drawings are composited, there is no way to decompose them back. Because composition itself is a sort of optimization by lossy compression, So you have only two options (1) redraw all graphics when mutation is required. Or (2) Make cached bitmap of each display element (like graph line) and just composite as your needs. This is just what the CALayers are doing.

4. Absolutely layer-based approach is far better. Any kind of free shape drawing (even it's done within GPU) needs a lot more processing power than simple bitmap composition (which will become two textured triangles) by GPU. Of course, unless your layers doesn't exceeds video memory limit.

I hope this helps.

Malamut