views:

438

answers:

1

I know that the CGContext cannot call it to draw directly, and it needs to fill the drawing logic in the drawInContext, and call the CGContext to draw using "setNeedsDisplay", so, I designed a cmd to execute, but it cause some problems... like this :

http://stackoverflow.com/questions/2617827/why-i-cant-draw-in-a-loop-using-uiview-in-iphone

I think the CGContext is very different from my previous programming experience....(I used HTML5 canvas, that allow me add more details, after I draw, so do the Java Swing) Actually, I want to know what is the suitable to implement these kind of thing in Apples' programmer mind. Thz.

+4  A: 

There are three approaches to what you're asking. You can draw everything in drawRect:, you can manage multiple layers, or you can draw in an image. Each has advantages, but first you need to think correctly about the problem so that you don't destroy performance.

Drawing happens constantly. Every time anything changes, there may be quite a lot of drawing that has to be done. Not the whole screen usually, but still a lot of drawing. Since drawRect: and drawInContext: can be called many times, they need to be efficient. That means that you don't want to do a lot of expensive calculations, and you don't want to do a lot of useless drawing. "Useless" means "won't actually be displayed because it's off screen or obscured by other drawing."

So in the usual case, you put your actual drawing code in drawRect:, but you do all your calculations elsewhere, generally when your data changes. For example, you read your files, figure out your coordinates, create CGPaths, etc whenever your data changes (which should be much less frequent then drawing). You save all the results into ivars, and then in drawRect: you just draw the final result. So in your loop example, you would probably have an NSArray of images in your view object, and in drawRect: you would draw them all in order.

Another approach is to create a separate layer for each image, set the image as the content, and then attach the layer to the view. You're done at that point. There is no more drawing code you need to write. Quartz handles layers very efficiently, so this can be a very good solution to a wide variety of problems.

Finally, you can composite everything into an image, and then stick that image in an image view, or draw the image directly in the view, or attach the image to a layer. This is a good solution if you have very complicated drawing (particularly using CGPath). This can be expensive if you're constantly changing things, since you have to create a new image context, draw the old image into the new context, draw on top of it, and then create a new image from the context. But it's good for a complicated drawing that doesn't change often.

But you're correct, CGContext is not like a canvas. It needs to be redrawn every draw cycle. You can do that yourself, or you can use another view object (like UIImageView) to do it for you. But it has to be done one way or another.

Rob Napier
I didn't get the idea of CGContext, why don't Apple implement a canvas instead, I think it is much easier to follow. My case is I will use the CGContext to do some animations stuff, do u think that multiple layer is suitable for me?
Tattat
For the case you describe where you are compositing various images, multiple layers is likely a good approach. Animations are very efficient with layers.
Rob Napier
+1 Good summary of different techniques
manifest
@Tattat: The design of the drawing process has to do with the way that content is presented to the screen on the Mac and iPhone. Incremental drawing like you've done using the HTML5 canvas tag and Java Swing isn't the best approach for these devices, and thus Apple uses a different approach. If you think of your views as being cached bitmaps that you have to recache with drawing changes, the drawing system becomes easier to understand.
Brad Larson
@Rob Napier, so...instead of drawing in CGContext directly, I should use "CGLayer"? o implement?@Brad Larson, Er... ...I see. So, I have a question for Apple approach. The HTML5 canvas / Java Swing can add more on top of current drawing.For example,I have two thing to draw. I draw a line, and draw a circle. In HTML5 canvas / Java Swing, I draw a line first, and then draw a circle. But in Apple approach, I cached line and circle, and draw it in one step. Is that right?
Tattat
@Rob Napier, Following the Apple's approach. If I making an application, a canvas for example. I need to keep redrawing the whole image instead of adding new things on top on it. Don't u think it is use more resource?
Tattat
The system has to redraw everything in any case in order to perform correct compositing, transparency, antialiasing, etc. The question is whether there is a canvas object hiding that from you or whether you are given control over it. You are correct that the performance is worse than a canvas if you do your part poorly (by doing excessive calculations and drawing), but it gives you the ability to optimize the drawing to your application and improve performance over a generic canvas. CGLayers may give you something more like what you're expecting with good performance, however.
Rob Napier