4

一見無作為に見えますが (ただし、特定のプログラムの実行中は通常一貫しています)、私のpresentRenderBuffer呼び出しは非常に遅いです。makeの呼び出しまで追跡したglFlush()のでpresentRenderBuffer、今はglFlush()presentRenderBuffer の直前に呼び出します。にタイマーを設定するglFlush()と、一見ランダムに 2 つのうちのいずれかが実行されます。

glFlush()また

1) 一貫して 0.0003 秒かかります

また

2) 約 0.019 秒と 0.030 秒を交互に繰り返す

最も奇妙なことは、これが描画コードから独立していることです。すべての描画コードをコメントアウトしてglClear()、 call だけを実行しても、2 つの結果のうちの 1 つがランダムに取得されます。

描画メソッドはCADisplayLink、次の設定でによって呼び出されます。

dLink = [[UIScreen mainScreen] displayLinkWithTarget:viewController selector:@selector(drawFrame)];
dLink.frameInterval = 1;
[dLink addToRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];

結果の 1 つが発生する原因を特定することは不可能であることがわかっています。誰でもアイデアを提供できますか？

4

2 に答える 2

3

iOS OpenGL ES 呼び出しで正確なタイミングを実行することは、一般に、デバイスに使用されるタイルベースの遅延レンダラーのため、少し注意が必要です。状態の変更、描画、およびその他のアクションは、シーンが表示される直前まで延期できます。

これにより、実際にはすべての遅延レンダリングがその時点で実行されるだけの場合glFlush()でも、コンテキストの外観が非常に遅くなることがよくあります。-presentRenderBuffer:

すべての描画コードをコメントアウトするが、glClear()これによる影響を受けないケース。交互の例で提示するさまざまなタイミングは、おおよそ 1/53 または 1/33 秒に対応します。これは、画面のリフレッシュ レートに一致するのに十分な時間だけブロックされている可能性があることを示しているようです。CADisplayLink は画面の更新と同期している必要がありますが、描画が少しずれていることがわかりました。

メインスレッドでこのテストを実行していますか? メインスレッドがわずかにブロックされ、画面の更新タイミングがわずかにずれている可能性があります。レンダリングをバックグラウンド スレッドに移動すると、この種の振動が減少しましたが、それでも CADisplayLink によってトリガーされていました。これを行うと、特にマルチコア iPad 2 で、レンダリング速度も向上しました。

glFlush()最後に、 iOS で OpenGL ES を使用する場合、明示的に使用する必要はないと思います。presentRenderbuffer:フレームを画面にレンダリングするために必要なのは、EAGLContext のメソッドだけです。glFlush()ここの OpenGL ES アプリケーションにはのインスタンスが 1 つもありません。あなたの場合は冗長かもしれません。

于 2011-08-17T17:25:39.353 に答える
1

問題と思われるものを見つけました。EAGLView にアタッチされたビュー コントローラが、本来あるべきウィンドウのルート ビュー コントローラとして設定されませんでした。代わりに、ビューはサブビューとしてウィンドウに手動で追加されました。これが修正されたとき (他のいくつかの関連する修正と共に)、drawFrame メソッドは画面の更新と完全に同期するようになりました。成功！

于 2011-08-22T08:06:18.850 に答える