2

現在、私は(理想的には)60 FPSで動作する​​を使用してWebGLコンテンツをレンダリングしています。また、setTimeoutを使用してAI、物理などを処理する「更新」プロセスを同時にスケジューリングしています。後者は、オブジェクトを1秒間に約30回更新する必要があり、実際には描画シーケンスの一部ではないため、後者を使用します。ほとんどの私のアニメーションはかなりハードウェアが集中しているので、実際のレンダリングパスの残りのCPUを節約するのは良い考えでした。JS/WebGLの更新 "スレッド"

私の質問はベストプラクティスの1つです。 setTimeoutsetIntervalは、特にブラウザにフォーカスがない場合は、バッテリの寿命やCPU消費量にはあまり関係しません。一方、​​を使用するか(または既存のレンダリングフェーズに直接更新を関連付ける)、毎秒厳密に必要な更新よりもずっと多くの更新を強制し、ブラウザにフォーカスがないときやブラウザが他の時に更新を停止する可能性があります「アニメーション」には不要とみなされます。

のコンテンツを更新するのに、のコンテンツは表示されません。

答えて

3

のsetTimeoutとのsetIntervalバッテリ寿命に特に親切ではなく、CPUの消費

のは、正直言ってみましょう:​​ではありませんどちらも。違いは、タブを離れるとRAFが自動的にオフになることです。 Page Visibility APIを使用すると、その動作はsetTimeoutでエミュレートすることができます。実際には、2つの間の電力消費の問題は知的に使用されているとほぼ同じです。

それ以外では、setTimeout\Intervalはあなたのケースでの使用には完全に適切です。あなたが気づいておきたいことは、レンダーループと完全に同期させるのが難しいことです。アニメーションの更新がヒットする前に、何度も描画してしまうことがあります。これにより、吃音が少なくなります。 60hzでレンダリングして30hzで更新する場合、それは大きな問題ではありませんが、それを認識したいと思うでしょう。

レンダリングループと完全に同期していることが重要な場合は、RAFコールバックの先頭にif(framecount % 2) { updateLogic(); }という文字列を置くだけで、更新を30hz(1フレームおき)に制限することができます。ドロー。

+0

ありがとうございます!私がレンダリングループに直接接続することについて考えることができる唯一の欠点は、ユーザーがタブを切り替えたときに更新が一時停止する可能性があることです。しかし、今考えているのは好ましい結果かもしれません(タブを切り替えた彼らは明らかにユーザーとして、アップデートの恩恵を受ける立場にない)。バックグラウンドで更新する必要があるものは、それだけで独自の間隔に入ることができます。 – sinisterchipmunk