Drawing UIImage's with blocks

I have a slight love affair with Quartz's drawing routines. I don't know what it is about them, but there is something I love about stroking rects and filling paths. It's like OpenGL for stupid people.

Anyways, during my love affair I got bit annoyed at having to subclass UIView every time i wanted to make a quick sprite, or overlay a one image on top of another.

CALayer's a are awesome and everything, but i still need to subclass UIView unless i want a bunch of layout mess every where.

So I thought wouldn't it be cool to be able to create UIImage's quickly and then just throw them into a CALayers or UIImageView's and worry about the rest later.
The above does just that, you give it a canvas size or more informally the size of the UIImage that you wish to generate.

It will create the CGBitmapContext with a RGB colorspace, and then you can draw to your hearts content.

You can treat the block almost like a you would drawRect. I say almost because it's not inserted into the graphics context stack, so some of the helper methods like [[UIColor blackColor] setFill] will not work, and you'll have to learn how to do it the 'proper way' (CGColorSetFillColor()). Just consider it a general rule, that if it renders something and doesn't take a CGContextRef you need an alternative method to use it inside this block.

Making UIImages with blocks

So i was going to post about something completely different today, but as i was typing i looked at my code, and thought it was verbose and a little bit ugly.

So i made it awesome, and as everyone knows to make your code awesome you add some blocks to it.

My problem was simple, i was faced with the need to create two CGBitmapContext, for the uniformed the following code is required to prepare a bitmap context for drawing.


So after a bit of thought, i decided what i really wanted was a method that did all of this for me, and meant that i didn't have to worry about constantly checking the code for leaks (DRY), and that was pleasant to look at and i came up with the above. The block that you pass in is given a fully formed CGBitmapContext, and the method returns a UIImage generated from that context. Almost like a UIView/CALayer.



So now your thinking, "Yeah, thats cool, but why the [INSERT FOUR LETTER WORD] would i want to use it ?" Well young grasshopper, have you ever wanted to mask a image in code? You know to do those trendy rounded corners ... well yes you can use CALayer's however the idea of using those off the main thread makes me uneasy, and we all know the cool kids do things in the background.


The above actually creates a rounded rect on the fly, and masks the image with it. It's made to be used in a category on UIImage. But look closer, yep thats right kids, no boiler plate, ZERO, NADA, 另, SQUAT (i think you get the point)!

I should take a moment to mention that the awesome code for the rounded rect comes from the awesome Oliver Drobnik, i have the utmost respect for this guy, not just for this snippet, but if you've ever seen his Rich text label and it's associated projects, you'll understand why real soon.

Offscreen drawing on the iPhone using NSOperations, CGImage, CGLayer

What?

Creating and or modifying images offscreen or in a background thread.

Why?

Chiefly for performance. The main thread of an iPhone application is usually fairly busy doing all sorts of things. By rendering complex images in the background, you can do all manor of things. In my case I wanted to know how to render an image larger than the size of the device screen, and then save that image to disk.

For my fellow lovers of NSOperationQueue(aka possibly the most awesome class in Cocoa), this allows you to bundle image processing and generation in to NSOperation subclasses or if you like the new hotness a block, and add it to the queue.

How?

Well with a lot of C. If you have ever overridden UIView's drawRect: then most of what is below should make perfect sense.

First thing is first, as we want to operate on our own thread we have to create everything ourselves. Primarily that means no quick calls to UIGraphicsGetCurrentContext().

The key thing to remember is that the drawing coordinates are inverted. This means that CGPoint(0.0f,0.0f) is actually the bottom left not the top left corner. I'm lead to believe this is a hold over from the Postscript drawing system that originated on the mac, and this is how the big boys do it. So stop whining and code.

Nicely it would appear that the UIImage representation methods automatically invert the image, so you only have to invert your coordinates for CGContext drawing calls.

Exactly How?

This is the process

*Create a CGColorSpace

*Create a CGBitmapContext

*Create a new CGLayer

*Get the the CGLayer's context

Draw into the context as you would normally, using the CGContext methods

*Render that CGLayer into the CGBitmapContext

(if you want an image)

*Create a CGImage from the CGBitmapContext

*Convert the CGImage into a UIImage

*Use one of the UIImageJPEGRepresentation or UIImagePNGRepresentation methods to get an image that can be saved to disk or sent over the wire etc.

NOTE: This code will not work unless you have a image named sample.jpg in your bundle or change the assignment to the backgroundImg variable.

Sample code

Go forth and code.