私は、CPU と適度な GPU のみを使用する GL ライブ壁紙を開発しています。私の古いテスト電話では、ほとんどの場合、フル 58 fps で実行できます。ただし、時折、エフェクトが増加し、レンダリング時間がフレームごとに 16 ミリ秒から 50 ミリ秒の間で変動します。たとえば、16 ミリ秒でいくつかのフレームをレンダリングし、ダース フレーム程度で最大 50 ミリ秒までスライドし、50 ミリ秒でさらにいくつかのフレームをレンダリングし、16 ミリ秒までスライドして戻って繰り返します。CPUガバナーをデフォルトの「オンデマンド」ではなく「パフォーマンス」（または不思議なことに「保守的」）に設定すると、フルスピードでフルエフェクトでレンダリングされることがわかりました。あるいは、ガバナーをそのままにして、コードにビジー ループを挿入すると (変数 100 をインクリメントし、
したがって、この電話では、私のアプリは GPU によってボトルネックになっているようですが、それはスロットル ダウンした場合のみです。さて、GLSurfaceView が GPU クロックに応じてより遅いレートでレンダリングされてもかまいませんが、ここでの問題は、アニメーションが流動的/フレームスキップ/流動的に見えるように、高フレームレートと低フレームレートを交互に繰り返すことです。 /frameskippy/など。毎秒数回。GPU クロックが狂ったように増減しているように見えますか?
RENDERMODE_WHEN_DIRTY を使用し、厳密なタイミングのスレッドで requestRender() を呼び出すことで目に見える改善が得られましたが、くそったれな GPU は増減し続けます。遅いクロックで可能な限り高速にレンダリングしないか、または単にジャンプして高いクロックにとどまらないのはなぜですか?
これまでに思いついた最善の解決策は、スライディング ウィンドウを使用して平均フレーム更新時間を検出し、2 つの値が収束するまでターゲット フレーム時間との差を適用することです。レンダリングの更新間隔は遅くなりますが、少なくともほぼ一定です。理論的にはうまくいきますが、定常状態に達するまでに数秒かかり、その間は見栄えが悪くなります。
3 つ目のオプションは、GLSurfaceView ソースを共食いしてカスタム バージョンを作成することだと思います。私が理解していることから、ブロッキング GL 呼び出しはそこで行われるため、レンダリング呼び出しのタイミングを合わせてそれに応じて反応する方がはるかに簡単です。ただし、そこには多くのコードがあり、それをいじり始める前に理解するのに多くの時間を費やさなければならないため、それを試みるのはあまり快適ではありません。さらに、GLSurfaceView のバージョン X が Android のバージョン Y とどの程度うまく機能するかを心配する必要があります。
そうは言っても、他に選択肢はありますか？これに対するより簡単な修正はありますか？