views:

54

answers:

2

Hi, I want to display so many images in table cells. I knew two methods to show an image.

One is creating an instance to UIImageView and show it

CGRect rect=CGRectMake(x,y,width,height);
UIImageView *image=[[UIImageView alloc]initWithFrame:rect];
[image setImage:[UIImage imageNamed:@"sample.jpg"]];

Another method is,

CGRect rect=CGRectMake(x,y,width,height);
[[UIImage imageNamed:@"sample.jpg"] drawInRect:rect];

Now, my question is, what is the difference between these two? Which one is efficient? Or someother function is available better than this?

Thanks in advance....

A: 

UIImageView is a UIView subclass. By adding it to the view hierarchy you get all the free benefits: animations, size properties, affine transoforms, etc. Plus, you are able to change the underlying UIImage any time you want.

On the other hand, calling drawInRect: will just draw the image where you tell it to, but not interact with the UIView hierarchy, so you don't gain any of the benefits from having it on the view hierarchy.

I would think (have not tried it), that drawing the image directly is faster, but I would think in most of the cases having a UIImageView is a better idea.

pgb
Oddly enough, drawing the image is slower because it's less direct than assigning it to an `UIImageView`
rpetrich
That's great to know, thank you!
pgb
Thanks for your valuable answers
Rajkanth
+3  A: 

Using the drawInRect: method has CoreGraphics draw the image into the active CGContext using the CPU. Assuming you're in a UIView's drawRect: method, this will paint the image into the view's buffer.

UIImageView uses whichever image is assigned to it as it's backing buffer instead of using the slower drawRect:. The GPU then references this buffer directly when the screen is composited via QuartzCore.

rpetrich
+1 for a GREAT answer. I've been trying to get my head around the distinction between those two for a while now. So `UIImageView` is always the way to go, then? Are there cases where `drawRect:`'ing the image directly is preferable?
Dan Ray
The only situation I can see it being slower is when compositing a static background scene from many small images and then animating content on top of it without changing the background. In that case the GPU will have to recomposite both the moving content over top and the entire background scene each frame. This is a corner case of course.
rpetrich