4

皆さん、

いくつかのダイヤルとスライダーをコーディングしている間 (たとえば、回転できる大きな音量ボタンなど)、標準の CGContextAddArc() が次のように使用されていることがわかりました。

- (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);

信じられないほど遅くなります。

iPad の場合 - いくつかの塗りつぶし/ストロークの円があり、ドラッグ中のクリーンな [self setNeedsDisplay] の更新は 1 秒あたり 10 回未満です。手描きの円 (下図) を使った非常に簡単なハックは、桁違いに高速でした。エミュレーターも同様です。

どうしてこれなの。通常の塗りつぶしとさまざまなグラデーション塗りつぶしの両方に当てはまるようです。私は何を間違っていますか？

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);
};
4

2 に答える 2

3

Quartz 2D のベクター描画操作は遅くなる可能性があるため、必要な場合にのみ再描画することをお勧めします。

あなたの場合、音量ボタンを一度描画してから、回転変換を使用してボタンを描画した UIView または CALayer を変換することをお勧めします。ビューを移動、回転、スケーリングするだけで、コストのかかる再描画をトリガーしません。コンテンツは既にテクスチャとしてキャッシュされており、GPU はこのラスタライズされたコンテンツをすばやく操作して、他のビューの上に合成できます。

この方法で再描画を回避すると、パフォーマンスが大幅に向上することがわかります。

于 2010-11-15T17:53:28.150 に答える
0

問題の一部 (大部分は解決済み)。

  1. 広範なベンチマークでは、半径 100 ～ 200 ピクセルの範囲の円のベクトル/直線パスを使用して完全な円を描画する場合と比較して、AddArc が実際に遅いことが示されています。部分的な円の場合、効果はそれほど顕著ではありません。これがベジエの数に関係しているかどうか疑問に思っています。

しかし：

  1. 以下のコードは、人が読むようにコンパイルされませんでした。M_PI は、含まれている固定小数点 DSP ライブラリ (x100 に設定) によって (3.14... * ((EVP_ARM7_ADJUST[(PLTF)])) に設定されることにより、実際に期待される 3.14etc ではありませんでした。

したがって、256 倍の大きすぎるエンド アーク ダブルを指定しました。

そして、問題を非常に顕著にしたのは後者でした（明らかに、下層の実装はただぐるぐる回っています..）。

そのため、問題は理解されました (そして、最適化された/ベンチマークされたバージョンを維持します)。

助けてくれてありがとう！

于 2010-11-15T20:59:44.297 に答える