views:

688

answers:

1

Alright, I have a UIView which displays a CGPath which is rather wide. It can be scrolled within a UIScrollView horizontally. Right now, I have the view using a CATiledLayer, because it's more than 1024 pixels wide.

So my question is: is this efficient?

- (void) drawRect:(CGRect)rect {
    CGContextRef g = UIGraphicsGetCurrentContext();
    CGContextAddPath(g,path);
    CGContextSetStrokeColor(g,color);
    CGContextDrawPath(g,kCGPathStroke);
}

Essentially, I'm drawing the whole path every time a tile in the layer is drawn. Does anybody know if this is a bad idea, or is CGContext relatively smart about only drawing the parts of the path that are within the clipping rect?

The path is mostly set up in such a way that I could break it up into blocks that are similar in size and shape to the tiles, but it would require more work on my part, would require some redundancy amongst the paths (for shapes that cross tile boundaries), and would also take some calculating to find which path or paths to draw.

Is it worth it to move in this direction, or is CGPath already drawing relatively quickly?

+3  A: 

By necessity Quartz must clip everything it draws against the dimensions of the CGContext it's drawing into. But it will still save CPU if you only send it geometry that is visible within that tile. If you do this by preparing multiple paths, one per tile, you're talking about doing that clipping once (when you create your multiple paths) versus Quartz doing it every time you draw a tile. The efficiency gain will come down to how complex your path is: if it's a few simple shapes, no big deal; if it's a vector drawn map of the national road network, it could be huge! Of course you have to trade this speedup off against the increased complexity of your code.

What you could do is use instruments to see how much time is being spent in Quartz before you go crazy optimizing stuff.

U62