4

これが起こることです：

  • 提案されているように、 drawGL 関数は のおかげでフレームの正確な最後に呼び出されusleepます。これにより、すでに安定したフレームレートが維持されています。

  • レンダバッファの実際のプレゼンテーションは で行われdrawGL()ます。これにかかる時間を測定すると、実行時間が変動し、アニメーションが途切れます。このタイマーは mach_absolute_time を使用するため、非常に正確です。

  • フレームの最後で、 を測定しtimeDifferenceます。はい、平均で 1 ミリ秒ですが、大きくずれており、0.8 ミリ秒から 1.2 ミリ秒の範囲で、最大 2 ミリ秒を超えるピークがあります。

例：

// Every something of a second I call tick
-(void)tick
{
  drawGL(); 
}

- (void)drawGL
{   
  // startTime using mach_absolute_time;

  glBindRenderbufferOES(GL_RENDERBUFFER_OES, viewRenderbuffer); 
  [context presentRenderbuffer:GL_RENDERBUFFER_OES];

 // endTime using mach_absolute_time;
 // timeDifference = endTime - startTime;
}

私の理解では、フレームバッファが作成されたら、フレームの複雑さに関係なく、レンダバッファを提示するには常に同じ努力が必要です? これは本当ですか？そうでない場合、どうすればこれを防ぐことができますか？

ちなみにこれはiPhoneアプリの例です。ここでは OpenGL ES について話していますが、これはプラットフォーム固有の問題ではないと思います。もしそうなら、何が起こっているのですか？そして、これは起こってはいけませんか？繰り返しますが、もしそうなら、どうすればこれを防ぐことができますか?

4

5 に答える 5

1

私のお気に入りの OpenGL 表現は、「実装固有」です。ここにとてもよく当てはまると思います。

于 2009-03-26T10:59:17.270 に答える
0

いくつかの理由から、高い一定のフレームレートに依存しないことが最善です。最も重要なのは、OSがバックグラウンドで処理を遅くする可能性があることです。タイマーをサンプリングして、各フレームに経過した時間を計算することをお勧めします。これにより、スムーズなアニメーションが保証されます。

于 2009-03-24T22:05:02.957 に答える
0

小数0.8->2.0を返しているにもかかわらず、タイマーがサブミリ秒レベルまで正確ではない可能性はありますか?

于 2009-03-25T21:01:39.170 に答える