Is CGContextAddArc really that slow (compared to a circle drawn with a few lines

Folks,

While coding up a few dials and sliders (e.g. like a big volume button one can rotate around) - I found that the standard CGContextAddArc() used like:

- (void)drawRect:(CGRect)rect {
    CGContextRef ctx = UIGraphicsGetCurrentContext();
    CGColorSpaceRef rgbColorspace = CGColorSpaceCreateDeviceRGB();  
    CGContextSetLineWidth(ctx, radius * (KE-KR)+8);
    CGContextSetStrokeColorWithColor(ctx,self.foregroundColor.CGColor);
    .... more some colour/width/etc settings
    ...

    CGContextAddArc(ctx, dx,dy,radius, 0, 2*M_PI, 0);

to be unbelievable slow.

On an iPad - with a handful of filled/stroked circles, less than some 10 clean [self setNeedsDisplay] updates/second during drag. A very quick hack with a hand-drawn circle (shown below) was several orders of magnitude faster. Same applies to the emulator.

Why is this. Seems to be the case for both a normal fill and various gradient fills. What am I doing wrong ?

Dw.

// Stupid replacement for CGContectAddArc() which seems to be very slow.
//
void CGContextAddCirlce(CGContextRef ctx, float ox, float oy, float radius)
{
    double len = 2 * M_PI * radius;
    double step = 1.8 / len; // over the top :)

    // translating/scaling would more efficient, etc..
    //
    float x = ox + radius;
    float y = oy;

    // stupid hack - should just do a quadrant and mirror twice.    
    //
    CGContextMoveToPoint(ctx,x,y);
    for(double a = step; a < 2.0 * M_PI -step; a += step) {
        x = ox + radius * cos(a);
开发者_如何转开发        y = oy + radius * sin(a);
        CGContextAddLineToPoint(ctx, x, y);
    };

    CGContextClosePath(ctx);
};

---

The vector drawing operations of Quartz 2D can be slow, which is why it is a good idea to redraw only when needed.

In your case, I would suggest drawing your volume button once, then transforming the UIView or CALayer into which you've drawn the button using a rotational transform. By simply moving, rotating, or scaling a view, you do not trigger an expensive redraw. The content is already cached as a texture, and the GPU can quickly manipulate and composite this rasterized content on top of your other views.

You'll find that avoiding redrawing in this manner will yield much improved performance.

---

Issue partly (mostly resolved).

1. Extensive benchmarking does show that AddArc is indeed slow compared to drawing a complete circle with a vector/straight-line path for circles in the 100-200 pixel radius range. For partial circles the effect is much less pronounced; am wondering if this is tied to the number of beziers.

BUT:

1. The code below did not compile as one would read it; M_PI was not the 3.14etc as actually expected by set to (3.14... * ((EVP_ARM7_ADJUST[(PLTF)])) by an included fixed-point DSP library (set to x100).

Hence it specified the end-arc double by a factor of 256 too large.

And it was the latter which did make the issue so noticeable (evidently the underlaying implementation just keeps going round and round and round..).

So issue now understood (and will keep an optimized/benchmarked version).

Thanks for the help!