Question

When I have a UIBezier and I stoke it on a view using drawRect I see the bezier is a a kind of volatile, I mean, it is really not drawn anywhere. Instead it is like it was written in a kind of buffer that corresponds to what I see on that view. I mean, if I invoke drawRect again using [self setNeedsDisplay] the bezier is gone and I can write other stuff.

On the other hand, if I draw a like on a CGContext using

CGContextStrokePath(ctx);

I am really writing the line to that context and there’s no way to erase it and if I call the same method again, it will write over the context that now has already one line drawn.

But what happens when I use a UIBezier command to write on a CGContext?

I mean, if I do something like

UIGraphicsPushContext(ctx);
CGContextSaveGState(ctx);
CGContextTranslateCTM(ctx, 0, height);
CGContextScaleCTM(ctx, 1.0, -1.0);
[myBezier stroke];
CGContextRestoreGState(ctx);
UIGraphicsPopContext();

is this line permanently written to ctx or is it volatile as before? The docs contain no information about it and are vague as always.

thanks

Answer 1

Whenever your view’s drawRect: gets called, UIKit has set up a graphics context for you to draw into. That’s why it appears that the bezier paths aren’t permanent; every time the view needs to be displayed there’s a fresh new context, and your paths get drawn into that. Each time through drawRect:, therefore, you can decide not to draw a particular path and it won’t be displayed.

There’s no way to remove a path once it’s been added to the context, but the next time the view is refreshed, there’s a new context with almost nothing in it. If you create your own graphics context, whatever you put into it is “permanent” — it will be there for the lifetime of the context.

The context basically consists of drawing instructions that will produce a “picture”. This is vague because the destination for a context — where the picture will be drawn — can be different things: an image file, a section of the device screen, possibly even a piece of paper. The context, once it’s full of drawing instructions, then gets rendered to its destination.

In the case of your view drawing, UIKit sets up that context for you and calls your drawRect:. There’s a certain amount of indirection here — you’re never really “drawing into a view”, always into a context. Your view essentially reserves and represents a section of the screen. UIKit asks you what you would like to put into that section, and gives you the graphics context so that you can convey that information. Then it takes the context, which is full of instructions, turns it into pixel data, and paints that in the area represented by your view.