Why is scrolling performance poor for custom table view cells having UISegmentedControl objects?

Question

I have a UITableView with custom cells that were defined in the xib file, and am experiencing poor scrolling performance (choppy) on my device when the cells have a UISegmentedControl on them. NSLog statements reveal that the cells are being allocated and reused as they ought. My code for cellForRowAtIndexPath method is below. Connections are made in the xib as per Apple's documentation. (Scrolls smoothly in simulator btw)

- (UITableViewCell *)tableView:(UITableView *)tableView
              cellForRowAtIndexPath:(NSIndexPath *)indexPath {

    static NSString *MyIdentifier = @"MyIdentifier";

    UITableViewCell *cell =  
           [tableView dequeueReusableCellWithIdentifier:MyIdentifier];

    if (cell == nil) 
    {
        [[NSBundle mainBundle] loadNibNamed:@"TableViewCell" 
                               owner:self  
                               options:nil];  
        cell = self.tvCell;
        self.tvCell = nil;
    }

    cell.layer.shouldRasterize = YES;     // build error is here

    UILabel *lbl = (UILabel *)[cell viewWithTag:1];

    [lbl setText:[NSString stringWithFormat:@"Q%i", indexPath.row+1]];  

    return cell;
}

Carruthers

Answer 1

Any drawing that a table cell has to do while it's being scrolled is going to cause performance issues; when you have a lot of subviews, there tends to be a lot of drawing going on, and that will—as you've observed—make your scrolling pretty choppy. There are a couple of ways to try to reduce that.

The first step is to make sure that your cells themselves, and as many of their subviews as possible, have their opaque properties set to YES. Opaque views don't have to get blended with the content underneath them, and that saves a lot of time.

You may also want to set your cells' layers to rasterize themselves, like this:

cell.layer.shouldRasterize = YES;
cell.layer.rasterizationScale = [UIScreen mainScreen].scale;

This will collapse your view hierarchy into one flat bitmap, which is the kind of thing Core Animation just loves to draw. Note that any animating views—activity indicators, for instance—will force that bitmap to be updated every time they change, i.e. a lot. In that case, you won't want the cell to rasterize everything; you might just use a subview with all of your relatively static views (e.g. labels) beneath another subview with any such dynamic content, and only have the first of those rasterized.

Belay

Noah, after adding the first line of code you suggested, and then also adding the QuartzCore framework so I can refer to the layer, I get build error: "request for member 'shouldRasterize' in something not a structure or union". Would you please say more about what is required to get those two lines of code working? – Carruthers

That error might come up if you don't have #import <QuartzCore/QuartzCore.h> in your .m; also, shouldRasterize is only available in iOS 3.2 and later. – Belay

Yes is imported in my .m file, and <QuartzCore/CALayer.h> also. But, nope, not using 3.2 (using 3.1.3). Must be the problem. Yeah, and I can't even build successfully targeting this device (iPodTouch) with iOS 3.2. Code signing error and another weird one regarding iOS 3.2. Both are here: [BEROR]CodeSign error: code signing is required for product type 'Application' in SDK 'Device - iPhone OS 3.2' [BWARN]warning: building with 'Targeted Device Family' set to iPhone only ('1') not supported with SDK 'Device - iPhone OS 3.2'. – Carruthers

So, is there a way to get rid of the choppiness of the scrolling without going to 3.2? 3.2 is just for the iPad anyway, right? When I used it in simulator mode an iPad version of the simulator came up. I need to address the scrolling issue on iPodTouch devices. – Carruthers

Any app that you submit to the App Store today needs to be built with the 4.0 SDK. If you set your target's "Deployment Target" to 3.1.x, it will still run on older devices while allowing you to use features of the newer SDK, like this one; in that case, you need to check at runtime (using -respondsToSelector:) whether CALayer implements the setShouldRasterize method. – Belay

Noah, I intend to test this and check off your answer as the correct one. Haven't been able to get back to this. – Carruthers

Noah, this might be just what the doctor ordered for the problem I'm having over here: #7420485 ... in my case I do have a lone view inside the cell that has its layer rotated around its center using Core Animation (sort of like a compass would rotate). I tried stopping it from animating while the table view is scrolling, but that gets messy pretty quickly - it should "just work". So now I'm wondering if just rasterizing the rotated layer would help. Hmm ... ! – Appointee

Well, this helped me to add almost 15 FPS to scrolling performance, but why rasterization decreases images' quality? – Volkan

@NoahWitherspoon couple things. opaque defaults to YES, so most views will be opaque. Also, aren't collection view cells and table view cells generally poor candidates for rasterization because the cells themselves are re-used so often? Scrolling through a table view or collection view, the cached bitmaps seem obsolete since the cells will be re-configured for new objects over and over. Unless I'm missing something.. – Mokas

@NoahWitherspoon or is this for scrolling performance generally, so in the context of scrolling down and up a few pixels, where a cell is not even recycled because it's visible the whole time? – Mokas

Answer 2

Make sure your identifier is 'MyIdentifier' in the xib. You'll get a good performance hit if it's not. I'm guessing that 'allocated and reused as they ought' means a few allocated on startup and no more allocated after. If that's true then you're probably all set.

Another way to improve performance is to construct your table view with code. It's a good deal faster than using xib's. When I construct table views I usually build them in IB, then copy over the frame values into code and construct in code.

Set aside some time to watch the WWDC 2010 performance video's. A lot of great information, I learn something new each time I watch them.

Loireatlantique