🙉 👩🏻‍🔧 🥢 HTML5キャンバスのパフォーマンスの改善 ↔️ 💫 💾

最近、私は幸運にも、翻訳に関する興味深い記事に出会えました。 今回は、HTML5キャンバスのパフォーマンスに関するHTML5Rocksの記事です。 著者は、アプリケーションを作成するときに開発者が立ち向かう特定の壁について書いています。 少し前に、古き良きゲームをCanvasに移植するときにも遭遇しました。

残念ながら、オリジナルのグラフィックはiframeを介して挿入されます。 写真を撮って画像を配置することはできますが、著者自身が関連するグラフと更新されるグラフを配置するので、それらへのリンクを投稿しました。 素敵な読書を！

エントリー

Appleの実験として始まったHTML5キャンバスは、インターネット上の2D ダイレクトグラフィックスで最も広く受け入れられている標準です。多くの開発者は、さまざまなマルチメディアプロジェクト、視覚化、ゲームでそれを使用しています。アプリケーションの複雑さが増すにつれて、開発者はパフォーマンスの壁に偶然に出くわします。

キャンバスの最適化には多くの「トリック」が散在しています。この記事の目的は、それらをまとめて、開発者が読みやすいリソースを作成することです。この記事には、コンピューターグラフィックスのすべての領域に適用される基本的な最適化と、キャンバスの実装が進化するにつれて変化するキャンバスの特定の手法の両方が含まれています。特に、GPUアクセラレーションが使用されると、説明されている手法のいくつかはあまり重要ではなくなります。必要に応じてこれが示されます。

この記事はHTML5キャンバスチュートリアルではないことに注意してください。ただし、HTML5Rocksの関連記事、「 Dive into HTML5」の章、およびMDNのレッスンを学習できます。

性能試験

HTML5キャンバスのペースの速い世界では、 JSPerf （ jsperf.com ）は、提案された最適化がすべて機能することを確認するのに役立ちます。 JSPerfは、開発者がJavaScriptパフォーマンステストを作成できるWebアプリケーションです。各テストは、取得しようとしている結果（たとえば、キャンバスのクリーニング）に焦点を当てており、さまざまなアプローチが含まれています。 JSPerfは、各オプションを可能な限り短時間で実行し、統計的に意味のある1秒あたりの反復回数を表示します。常により良いものです！

JSPerfページへの訪問者は、ブラウザでテストを実行し、JSPerfが正規化された結果をBrowserscope （ browserscope.org ）に保存できるようにします。この記事の最適化手法はJSPerfに保管されているため、いつでも戻って、この手法またはその手法がまだ適用可能かどうかに関する最新情報を確認できます。これらの結果を記事で使用されているグラフとして表示する小さなヘルパーアプリケーションを作成しました。

この記事のすべてのパフォーマンステストの結果は、ブラウザーのバージョンに関連付けられています。これは、ブラウザがどのOSで起動されたのか、さらに重要なことには、テストが行われたときにHTML5キャンバスハードウェアアクセラレーションがオンになっていたかどうかがわからないため、制限のようです。アドレスバーに「 about:gpuと入力すると、Chromeでハードウェアアクセラレーションが有効になっているかどうかを確認できます。

仮想キャンバスで事前レンダリング

同様のプリミティブを多くのフレームにわたって画面に描画する場合（ゲームを作成する場合によくあることです）、ステージ外で大きな部分を描画することで、パフォーマンスを大幅に向上させることができます。予備レンダリングでは、一時的な画像が描画される仮想（または仮想）キャンバスを使用し、仮想キャンバスを表示可能なキャンバスにコピーします。コンピュータグラフィックスに精通している人にとって、この手法はディスプレイリストとも呼ばれます。

たとえば、1秒あたり60フレームでマリオを再描画するとします。各フレームに彼の帽子、口ひげ、「M」を描くか、アニメーションを開始する前に事前に描くことができます。

事前レンダリングなし：

 // canvas, context are defined function render() { drawMario(context); requestAnimationFrame(render); }

事前レンダリング：

 var m_canvas = document.createElement('canvas'); m_canvas.width = 64; m_canvas.height = 64; var m_context = m_canvas.getContext('2d'); drawMario(m_context); function render() { context.drawImage(m_canvas, 0, 0); requestAnimationFrame(render); }

requestAnimationFrameに注意してください。requestAnimationFrameの使用方法については、後ほど詳しく説明します。次のグラフは、事前レンダリング（ jsperf ）を使用する利点を示しています：グラフ。

この手法は、レンダリングが難しい場合に特に効果的です（drawMario）。良い例は、テキストのレンダリングです。これは非常に高価な操作です。事前レンダリングテキスト（ jsperf ）を使用すると、パフォーマンスが劇的に向上します。グラフ

可能性として、上記の例では、「事前にレンダリングされたルーズ」テストのパフォーマンスが低いことがわかります。事前レンダリングする場合、一時キャンバスのサイズがイメージに対して「きつい」ことを確認することが重要です。そうしないと、大きなキャンバスを別のキャンバスにコピーするときにパフォーマンスが向上し、パフォーマンスが低下します（ターゲットキャンバスのサイズの関数のように見えます）。上記の例に適したキャンバスは次のとおりです。

 can2.width = 100; can2.height = 40;

大と比較して：

 can3.width = 300; can3.height = 100;

グループ通話

レンダリングは高価な操作であるため、コマンドの長いリストを使用して描画ステートマシンをロードし、それらをビデオバッファーにアップロードする方がはるかに効率的です。

たとえば、複数の線を描画する場合、すべての線で1つのパスを作成し、1回の呼び出しで描画することをお勧めします。つまり、個々の線を描くよりも：

 for (var i = 0; i < points.length - 1; i++) { var p1 = points[i]; var p2 = points[i+1]; context.beginPath(); context.moveTo(p1.x, p1.y); context.lineTo(p2.x, p2.y); context.stroke(); }

1本のポリラインを描画する方が適切です：

 context.beginPath(); for (var i = 0; i < points.length - 1; i++) { var p1 = points[i]; var p2 = points[i+1]; context.moveTo(p1.x, p1.y); context.lineTo(p2.x, p2.y); } context.stroke();

これはキャンバスにも適用されます。たとえば、複雑なパスを描画する場合、セグメントを個別に描画する（ jsperf ）： graphよりも、すぐにすべてのポイントを配置する方が適切です。

ただし、canvasにはこのルールの重要な例外があることに注意してください：描画されるオブジェクトのプリミティブが周囲に小さな長方形（境界ボックス）を持っている場合、それらを個別に（ jsperf ）描画する方が効率的であることがわかります。

不要な状態変更を避ける

Canvasはステートマシンに基づいて実装されます。ステートマシンは、塗りつぶしスタイルやストロークスタイルのほか、現在のパスを形成する以前のポイントを追跡します。最適化しようとすると、描画に集中したくなる誘惑があります。ただし、ステートマシンでの操作もコストにつながります。

シーンで複数の塗りつぶしの色を使用する場合、キャンバス上の場所よりも色でペイントする方が安価です。浅いストリップにテクスチャを描画するには、線を描画し、色を変更し、次を描画します。

 for (var i = 0; i < STRIPES; i++) { context.fillStyle = (i % 2 ? COLOR1 : COLOR2); context.fillRect(i * GAP, 0, GAP, 480); }

または、すべての偶数バンドと奇数バンドを描画します。

 context.fillStyle = COLOR1; for (var i = 0; i < STRIPES/2; i++) { context.fillRect((i*2) * GAP, 0, GAP, 480); } context.fillStyle = COLOR2; for (var i = 0; i < STRIPES/2; i++) { context.fillRect((i*2+1) * GAP, 0, GAP, 480); }

これらのメソッドの比較は、次のテスト（ jsperf ）で示されています： graph

予想どおり、道路の状態を操作するため、最初のオプションは遅くなります。

キャンバス全体ではなく、違いのみを描く

ご想像のとおり、描画する画面の小さい部分ほど安価です。再描画の間にわずかな違いしかない場合、違いのみをレンダリングすることでパフォーマンスを大幅に向上させることができます。つまり、レンダリングする前に画面全体をクリアするよりも：

 context.fillRect(0, 0, canvas.width, canvas.height);

ドロアブルの境界ボックスを見て、それだけをクリアします。

 context.fillRect(last.x, last.y, last.width, last.height);

これは、画面を横切る白い点（ jsperf ）を含む次のテストで示されています： graph 。

コンピュータグラフィックスが得意であれば、「再描画領域」と呼ばれるこの手法を知っておく必要があります。この手法では、以前の境界ボックスが保存され、レンダリングごとにクリアされます。

このテクニックは、このニンテンドーJavaScriptエミュレーターの説明のように、ピクセル単位のレンダリングにも適用されます。

複雑なシーンにレイヤードキャンバスを使用する

前述のように、大きな画像のレンダリングは高価であり、避けるべきです。オフスクリーンバッファー（事前レンダリングセクション）を使用することに加えて、互いに積み重ねられたキャンバスを使用できます。最上位レイヤーの透明度を使用して、GPUを使用してレンダリング中にアルファチャネルを適用できます。次のように、絶対に配置された2つのキャンバスを重ねて使用します。

 <canvas id="bg" width="640" height="480" style="position: absolute; z-index: 0"> </canvas> <canvas id="fg" width="640" height="480" style="position: absolute; z-index: 1"> </canvas>

単一のキャンバスを超える利点は、上部をレンダリングまたはクリーニングするときに、背景に影響を与えないことです。ゲームまたはマルチメディアアプリケーションを2つのレイヤーに分割できる場合、それらを異なるキャンバスに描画してパフォーマンスを大幅に向上させることをお勧めします。次のグラフは、1つのキャンバスと、必要に応じて最上層（ jsperf ）を再描画またはクリーニングするキャンバスとの単純なバージョンを比較したグラフです。

多くの場合、欠陥のある人間の認識から恩恵を受けることができ、背景を1回または1回以下の頻度でしか描画できません（ユーザーの注意のほとんどを描画します）。たとえば、トップレイヤーをNレンダリングして、背景を1回だけ描画できます。

この方法は、アプリケーションがこのような構造でより適切に機能する場合、他の任意の数のレイヤーにも適用されます。

shadowBlurを避ける

他のグラフィカル環境と同様に、HTML5キャンバスでは開発者がプリミティブをぼかすことができますが、この操作は非常に高価です。

 context.shadowOffsetX = 5; context.shadowOffsetY = 5; context.shadowBlur = 4; context.shadowColor = 'rgba(255, 0, 0, 0.5)'; context.fillRect(20, 20, 150, 100);

このテストは、影の有無にかかわらず描画された同じシーンとパフォーマンスの決定的な違い（ jsperf ）を示しています。

画面をクリアするさまざまな方法

キャンバスは即時グラフィックモードのパラダイムなので、シーンは各フレームで再描画する必要があります。このため、キャンバスのクリーニングは、アプリケーションおよびゲームで基本的に重要な操作です。

不要な状態変更の回避セクションで述べたように、キャンバス全体をクリアすることはしばしば望ましくありませんが、これを行う必要がある場合、context.clearRect（0、0、width、height）を呼び出すか、ハックを使用します：canvas.width = canvas .width;。

執筆時点では、clearRectは幅のリセットを追い越しますが、場合によっては、Chrome 14（ jsperf ）： graphで幅のリセットを使用する方がはるかに高速です。

これらのトリックは、キャンバスの実装に大きく依存しているため、注意してください。詳細については、キャンバスのクリーニングに関するSimon Sarrisの記事を参照してください。

整数以外の座標を避ける

HTML5キャンバスはサブピクセルレンダリングをサポートしており、無効にする方法はありません。整数以外の座標で描画する場合、自動的にアンチエイリアスを使用して線を滑らかにします。 Seb Lee-Delisleの記事のサブピクセルパフォーマンスの視覚効果を以下に示します。
うさぎ

平滑化されたスプライトが必要なものではない場合、Math.floorまたはMath.round（ jsperf ）： graphを使用して座標を変換する方がはるかに高速です。

非整数座標を整数座標に変換するには、いくつかの機知に富んだ手法があります。そのほとんどは、数に半分を追加し、ビット単位の操作を適用してカマキリを削除することに基づいています。

 // With a bitwise or. rounded = (0.5 + somenum) | 0; // A double bitwise not. rounded = ~~ (0.5 + somenum); // Finally, a left bitwise shift. rounded = (0.5 + somenum) << 0;

ここでパフォーマンスの完全な内訳（ jsperf ）：グラフ。

この最適化方法は、キャンバスの実装がGPUアクセラレーションになった瞬間から意味をなさなくなり、非整数座標をすばやく描画できます。

「requestAnimationFrame」でアニメーションを最適化する

比較的新しいrequestAnimationFrame APIは、ブラウザでインタラクティブアプリケーションを実装するために推奨されます。特定の頻度で描画するようにブラウザに指示する代わりに、レンダリングを呼び出すように丁寧にブラウザに要求し、完了したら通知します。さらに、ページが非アクティブな場合、ブラウザは描画しないほどスマートです。

requestAnimationFrame呼び出しは60 FPSを対象としていますが、それを保証するものではないため、最後のレンダリングから経過した時間を追跡する必要があります。次のようになります。

  var x = 100; var y = 100; var lastRender = new Date(); function render() { var delta = new Date() - lastRender; x += delta; y += delta; context.fillRect(x, y, W, H); requestAnimationFrame(render); } render();

requestAnimationFrameの使用は、キャンバスとWebGLなどの他の技術の両方に適用されることに注意してください。

この記事の執筆時点では、APIはChrome、Safari、Firefoxでのみ使用可能でしたので、慎重に使用する必要があります。

ほとんどのモバイルキャンバスの実装は遅い

モバイルプラットフォームについて話しましょう。残念ながら、執筆時点では、Safari 5.1を搭載したiOS 5.0ベータ版のみがキャンバスハードウェアアクセラレーションを使用していました。これがないと、モバイルブラウザには、最新のキャンバスアプリケーションに十分なCPUが搭載されていません。上記のいくつかのテストは、デスクトップと比較してモバイルプラットフォームのパフォーマンスが低下する順序を示しており、成功が期待できるクロスプラットフォームアプリケーションのタイプを大幅に制限しています。

おわりに

この記事では、生産的なHTML5キャンバスアプリケーションの開発に役立つ、有用な最適化の広範なセットについて説明しました。ここで何か新しいことを学んだので、先に進み、素晴らしい作品を最適化します。または、ゲームや最適化アプリをまだお持ちでない場合は、 Chrome ExperimentsまたはCreative JSを参考にしてください。

参照資料

即時モードと保持モード。
その他のHTML5Rocks キャンバスの記事。
Dive into HTML5のCanvasセクション。
JSPerfを使用すると、開発者はJSパフォーマンステストを作成できます。
Browserscopeは、ブラウザーのパフォーマンスデータを保存します。
JSPerfView ：JSPerfテストをグラフとして表示します。
キャンバスのクリアに関するSimonのブログ投稿。
サブピクセルレンダリングのパフォーマンスに関するSebastianのブログ投稿。
requestAnimationFrame使用に関するPaulのブログ投稿。
JS NESエミュレーターの最適化に関するベンの講演。

お気に入りのコメント

ミケネレバリン＃

モバイルデバイスでは、状況はまったく逆です-多層キャンバスは非常に遅いため、1 +シーンプレレンダリングを背景に使用する必要があります（そして、divの後ろはキャンバスのサイズであり、キャンバスの背景も不可解なことに非常に遅いため）。
もっとトリッキーな方法で、携帯電話で完全に通常の速度のキャンバスを実現できます。

TheShock ＃

...
コードから判断すると、各フレームにグラフィックプリミティブを描画する代わりに、バッファに一度描画してからバッファから描画する方がよいことを意味します。数学に従って、.arcまたは曲線で行われる数学計算に従って円を描画するのは本当です。 bezierCurveToで行われる計算は、適切なサイズの画像を単にコピーするよりもはるかに遅くなります。

しかし、実際の「ダブルバッファリング」はあまり意味がありません。ブラウザには独自のバックバッファがあり、バックバッファをメインレイヤに描画します。
1.時間がかかりすぎる
2.レンダリングのボトルネックを探すのが難しくなります
...

HTML5キャンバスのパフォーマンスの改善