views:

2362

answers:

5

I'm using a whole bunch of CALayers, creating a tile-based image not unlike GoogleMaps (different versions of the same image with more/less detail).

The code I'm using to do this is:

UIImage* image = [self loadImage:obj.fileName zoomLevel:obj.zoomLevel];
[CATransaction setValue:(id)kCFBooleanTrue
        forKey:kCATransactionDisableActions];
obj.layerToAddTo.contents = [image CGImage];
[CATransaction commit];

I don't really feel like loading the CGImage from file using CoreGraphics because I'm lazy. But I will if there's a big performance boost! LoadImage just mangles a string to get the right path for loading said image, and obj is a NSObject-struct that holds all the info I need for this thread.

Help?

+3  A: 

There's not a big performance boost - if anything it's the other way around. By going throuh UIImage to load up your images, you'll get all the benefits of caching that it does for you and it'll be a very speedy critter to use with your various CALayers.

heckj
I'd just add that Shark is your friend here. If you want to see where to improve your code performance, profile it, and see where it's actually spending time rather than taking stabs in the dark.
NilObject
A: 

I don't have a definite answer but I'd guess that you'd see a slower load time when using UIImage than you'd see when using CGImage. With CGImage, you specify the image type (jpg or png) during creation, but with UIImage, the object type needs to be determined dynamically. Admittedly, this is probably as simple as looking at the first few bytes of the image file, but it might not be.

Once the image is actually in use, I wouldn't imagine that there'd be any difference at all between using the CGImage that internally represents a UIImage vs. using a CGImage you created yourself. I'd think they'd be exactly equivalent.

smeger
Regarding your first point, detecting the difference between a PNG and a JPG is nearly instant. Each of these types has magic codes at the front of the file that allow a quick comparison to determine what type it is.
NilObject
Yeah, that's what I was referring to, but my point was more that I don't actually know what Apple's implementation of file-type determination is, so I couldn't say definitely that that's how they did the determination. Oh, and obviously, there will be big differences in either loading time or first render time depending on the image type. Some image types are quicker to decode than others.
smeger
+1  A: 

I just tried this and using pure CoreGraphics to load the image rather than using UIImage gave a noticeable speed improvement when loading many images in one go.

smeger
A: 

"I just tried this and using pure CoreGraphics to load the image rather than using UIImage gave a noticeable speed improvement when loading many images in one go."

How did you avoid using a UIImage? Or more precisely, how do you load an image file directly into CoreGraphics without going through a UIImage?

A: 

One reason why NOT to use UIImage -imageNamed: to load images is that they are stored in the internal cache and that cache is not cleared in low memory situation.

Phil M