Why does drawRect scroll slower than UIImageView for large images in custom UITableViewCell

I have a custom UITableViewCell modelled exactly from the custom UITableViewCell tutorials found here - http://developer.apple.com/library/ios/#samplecode/AdvancedTableViewCells/Introduction/Intro.html#//apple_ref/doc/uid/DTS40009111

and here - http://developer.apple.com/library/ios/#samplecode/TableViewSuite/Introduction/Intro.html#//apple_ref/doc/uid/DTS40007318

Everything is rendered using drawRect and the s开发者_运维问答crolling speed is 55 FPS when drawing 3 strings and 1 image. The image is drawn via -

[self.sampleImage drawInRect:CGRectMake(0, 0, 55, 55)];

Oddly enough, the scrolling speed reduces to 25 FPS when I render the same image but in a bigger area

[self.sampleImage drawInRect:CGRectMake(0, 0, 320, 80)];

I experimented with bigger images in drawRect in Apple's sample code and sure enough the frame rate drops to 25 FPS.

The catch is that the FPS goes back up to 55 when I draw the strings and display the image via a UIImageVew.

• How can large images be drawn using drawRect in a UITableViewCell while maintaining 50 FPS scrolling speed?

• Can UIImageView ever be faster than drawing an image in drawRect (for a UITableViewCell) ?

• Are there any GPU vs CPU forces at play?

The drawRect will use core graphics to draw the image onto the screen where it uses the CPU. if you use UIImageView it will use GPU hence it is faster.

Solution is to not use drawRect.

If you absolutely need to use drawRect then you may need to draw it before scroll to some cache location/ cache the drawing and use that image for UIImageView.

@darcwader has it pretty much spot on. I think the reason why all the examples use drawRect is because it's more expensive initially (to set up the cells) but afterwards its much cheaper to animate them. For large images however it's going to be significantly more costly to draw them up and if you're scrolling past multiple ones the benefits of using drawRect aren't realized.