Canvas 2DとWebGL/WebGPUのレンダリング経路の違い

3つのAPIは「描き方のモデル」が違う

Canvas 2D・WebGL・WebGPUはどれも <canvas> 要素に描画しますが、性能特性が大きく異なるのは、解像度やGPUの有無以前に描画コマンドをどう組み立て、どこで状態を持つかというモデルが根本から違うからです。Canvas 2Dは命令ごとに即描く即時モード、WebGLは暗黙の状態を切り替えて描くグローバル状態機械、WebGPUは状態を固めてコマンドを束ねるコマンドバッファ方式です。この3つの違いを原理で押さえると、「滑らかにならない」「ドローコールが多すぎる」といった症状を、API選択の問題として切り分けられます。最終的にどのAPIで描いた絵も、ブラウザの合成（コンポジット）段でページの他のレイヤーと重ね合わされて画面になります。

Canvas 2D：即時モードという手軽さと限界

Canvas 2Dは getContext("2d") で得る CanvasRenderingContext2D に対し、fillRect や arc といったメソッドを呼ぶと**その場で（即座に）**ピクセルが塗られる、即時モード（immediate mode）のAPIです。保持モード（retained mode）のDOMやSVGと違い、描いた図形は「オブジェクト」として残らず、結果のビットマップだけが残ります。だから再描画は毎回ゼロから描き直しで、シーングラフの管理は完全にアプリ側の責任です。

状態は描画コンテキストが1セットだけ持ちます。fillStyle・lineWidth・現在の変換行列（CTM）・クリップ領域などはコンテキストのプロパティで、save()/restore() で状態スタックに退避・復元します。次のコードは「状態を変えてから描く」という即時モードの基本形です。

const ctx = canvas.getContext("2d");
ctx.save();
ctx.translate(100, 50);        // 現在の変換行列を更新
ctx.fillStyle = "tomato";      // 以降の塗り色を設定
ctx.fillRect(0, 0, 80, 80);    // この時点で即描画される
ctx.restore();                 // 変換・色などを退避前へ戻す

性能の限界は、描画1回ごとにCPUからAPI呼び出しが発生する点にあります。実装はGPU合成されることも多いものの、APIの粒度は1図形単位で、数万個の図形を毎フレーム個別に呼べばCPU側のコマンド発行がボトルネックになります。三角形を大量に流す・シェーダで陰影を計算するといった用途には構造的に向きません。逆に、図形数が限られたチャート・注釈・2Dゲームのスプライト程度なら、最小の学習コストで十分な性能が出ます。

WebGL：グローバル状態機械の柔軟さと罠

WebGLはOpenGL ES 2.0/3.0をブラウザに移したAPIで、本質は巨大なグローバル状態機械です。描画は「描く対象を直接指定する」のではなく、bind（束縛）でカレントな対象を切り替え→各種パラメータを設定→drawArrays/drawElements で発射という手順を踏みます。何を描くかは、その瞬間にバインドされているバッファ・テクスチャ・シェーダプログラムという暗黙の状態で決まります。

gl.bindBuffer(gl.ARRAY_BUFFER, posBuffer);   // カレントの頂点バッファを切り替え
gl.vertexAttribPointer(0, 3, gl.FLOAT, false, 0, 0);
gl.useProgram(program);                       // カレントのシェーダを切り替え
gl.bindTexture(gl.TEXTURE_2D, tex);
gl.drawArrays(gl.TRIANGLES, 0, vertexCount);  // 現在の状態一式で描画

GPU上で動くのは2種類のシェーダです。頂点シェーダが頂点ごとに座標変換を行い、ラスタライザがプリミティブをピクセルに分解し、フラグメントシェーダがピクセルごとの色を計算します。頂点データは ArrayBuffer 由来のTypedArrayとしてGPUへアップロードします。この仕組みにより、数十万頂点の変換やピクセル単位の陰影計算をGPUへ丸投げでき、Canvas 2Dでは不可能な規模の描画が可能になります。

罠は2つあります。第一に状態漏れで、どこかでバインドしたまま戻し忘れた状態が次の描画に影響し、再現の難しいバグになります。第二にドローコール過多です。draw* 一発ごとにブラウザ（と裏のドライバ）が状態の妥当性を検証するため、CPUオーバーヘッドが無視できません。

WebGPU：パイプラインとコマンドバッファ

WebGPUは状態機械の弱点を、設計レベルで解消するために作られた新しいAPIです（背後はVulkan/Metal/Direct3D 12）。中核は2つの考え方です。

ひとつはレンダーパイプラインオブジェクト。シェーダ・頂点レイアウト・ブレンド設定・出力フォーマットといった「描画の構成」を、描画前に createRenderPipeline で1つのイミュータブルなオブジェクトに固めて検証します。WebGLが描画のたびに散在する状態を都度検証していたのに対し、WebGPUは検証を構築時へ前倒しし、描画ループでは完成済みパイプラインを差すだけにします。

もうひとつがコマンドバッファです。描画命令は即実行されず、CommandEncoder に記録されてコマンドバッファになり、queue.submit で初めてGPUへ一括投入されます。即時モードのCanvas 2Dとは対照的に、命令の「記録」と「実行」が明確に分離されています。

const encoder = device.createCommandEncoder();
const pass = encoder.beginRenderPass(renderPassDescriptor);
pass.setPipeline(pipeline);     // 検証済みパイプラインを差す
pass.setBindGroup(0, bindGroup);
pass.draw(vertexCount);         // ここではまだ記録するだけ
pass.end();
device.queue.submit([encoder.finish()]); // バッファをまとめてGPUへ

リソースはバインドグループとしてまとめて束ね、setBindGroup で一括切り替えします。WebGLの個別バインドの集積を、整理された単位に置き換えた形です。さらにWebGPUはコンピュートシェーダ（dispatchWorkgroups）を標準で持ち、描画を伴わない汎用GPU計算（GPGPU）——物理シミュレーション・画像処理・機械学習——を、WebGLのような描画への偽装なしに書けます。

適材適所：何を基準に選ぶか

選択は「新しいから」「速そうだから」ではなく、描画の規模とGPU計算の要否で決めます。図形数が限られ2Dで足りるならCanvas 2Dが最も手軽で、学習・保守コストも最小です。3Dや大量頂点が必要で、広い実行環境への対応や既存ライブラリ（多くは内部でWebGLを使う）を優先するならWebGLが現実解です。極端に高い描画負荷、明示的なGPU計算（GPGPU）、最新世代の性能を引き出したい場合はWebGPUが適します。

WebGPUは新しいぶん、対応ブラウザの確認とフォールバック設計（WebGLや2Dへの代替）が要ります。いずれを選んでも、最終的な体感速度はメインスレッドを詰まらせないことに左右されるため、重い前処理はWebパフォーマンスの観点でワーカーへ逃がし、描画はブラウザのレンダリングパイプラインのフレーム予算（おおむね16.6ms）に収める設計が前提になります。