UIImageView displays MUCH faster than either CG or CALayer. Anyone know why?

Question

I've written an app to test image performance on iOS. I've tried 3 different views, all displaying the same large PNG. The first is a view that draws using CGContextDrawImage(). The second sets self.layer.content. The third is a plain UIImageView.

The image used is created using -[UIImage initWithContentsOfData:] and cached in the viewController. Each test repeatedly allocs a view, adds it to the view hierarchy and then removes it and releases it. Timings are taken from the start of loadView to viewDidAppear and given as fps (effectively, view draws per second).

Here are the results from an iPad 1 running 5.1 using a 912 x 634 unscaled image:

CGContext:    11 fps
CALayer:      10 fps
UIImageView: 430 fps (!)

Am I hallucinating? It seems almost impossible that UIImageView can draw that fast, but I can actually watch the images flicker. I tried swapping between two similar views to defeat possible caching, but the frame rate was even higher.

I had always assumed that UIImageView was just a wrapper for -[CALayer setContent]. However, profiling the UIImageView shows almost no time spent in any drawing method that I can identify.

I'd love to understand what's going on. Any help would be most appreciated.

Please edit your question to include the code that you timed in each of the cases, or a link to it. — Peter Hosey
The code is part of a larger app used to test our proprietary game code. It'll take a couple hours to pull out the relevant bits. In the meantime, I'd be happy to fill you in on any specific details you're missing from the above description. — John Graziano
"Timings are taken from the start of loadView to viewDidAppear" -- that seems a little bogus, since viewDidAppear might be called before the view actually shows up on screen. If you aren't forcing the screen to update, you're not really timing anything useful; you might create and destroy several UIImageViews but only one actually gets drawn. I wonder if UIImageView is setting its layer's content on-demand in -layoutSubviews -- that's certainly how I'd do it, to ensure that I touched the layer only once per screen update. — Kurt Revis
Very interesting, Kurt. I knew viewDidAppear was a bit flaky, but I did not know that it can get called before a view draws. I'll try out your suggestion and see what the results are. — John Graziano
@JohnGraziano: I'm not sure what “flakiness” you're referring to, but what Kurt is referring to is the documented behavior of the method: It's called when the view is added to a superview, which necessarily (in the normal case) happens before the view is told to draw. — Peter Hosey

lukasz lukasz · Accepted Answer · 2012-04-19T06:06:32

Here is my idea.

When you modify a UIView hierarchy, by either adding, removing or modifying some view, no actual drawing is performed yet. Instead the view is marked with 'setNeedsDisplay', and is redrawn the next time the runloop is free to draw.

In fact, if your testing code looks something like this (I can only guess):

for (int i=0; i<10000; i++) {
     UIImageView* imageView = [[UIImageView alloc] initWithFrame:frame];
     [mainView addSubview: imageView];
     [imageView setImage: image];
     [mainView removeSubview: imageView];
}

than the runloop is blocked until this for loop is done. The view hierarchy is drawn only once, the measured performance is that of allocating and initializing objects.

On the other hand, the CGContextDrawImage() is free to draw right away, I think.

UIImageView displays MUCH faster than either CG or CALayer. Anyone know why?

3 Answers