ブラウザ上のリアルタイム生成表現：WebGLシェーダーとGPU負荷の実務的な検討

ブラウザでの生成的ビジュアルはWebGLとGPUシェーダーで実現できるが、フラグメントシェーダーの負荷は描画するピクセル数にほぼ比例する。表現の選択より先に、解像度とフレームレートのどちらを優先するかという運用上の判断が必要になる。

ブラウザ上で動く生成的なビジュアルは、いまや特別な環境を必要としない。WebGLはほとんどのブラウザで利用でき、GPUを使ったリアルタイム描画が標準の機能として手に入る。もっとも、動くことと、実運用に耐えることのあいだには距離がある。ここでは表現の見た目ではなく、負荷がどこで発生し、何がボトルネックになるかを実装の観点から整理する。

フラグメントシェーダーの負荷はピクセル数で決まる

画面全体を覆う生成表現では、多くの計算がフラグメントシェーダー、つまりピクセルごとの処理として実行される。ここで見落とされがちなのは、負荷がシーンの複雑さではなく、描画されるピクセルの総数にほぼ比例するという点だ。オブジェクトを減らしても、画面を覆う全画面シェーダーの計算量は変わらない。

さらに厄介なのが devicePixelRatio の存在だ。高解像度ディスプレイでは、CSS上の1ピクセルが物理的には2×2の4ピクセルに展開される。描画バッファをデバイス解像度に合わせると、計算量は名目上の解像度の4倍になる。画像フォーマットの選択と同様に、ここでも「見た目の解像度」と「実際に処理する画素数」を分けて考える必要がある。MDNのWebGLドキュメントも、描画バッファのサイズを表示サイズと切り離して管理することを基本としている。

フレーム予算は16.7ミリ秒しかない

60fpsを目標にすると、1フレームあたりの予算はおよそ16.7ミリ秒になる。この時間にはシェーダーの実行だけでなく、JavaScriptの処理、レイアウト、合成もすべて含まれる。requestAnimationFrame は描画のタイミングを合わせてくれるが、処理が予算を超えればフレームは単純に落ちる。

実装でよく起きる失敗は、メインスレッドで重い計算を同期的に走らせてしまうことだ。シェーダー側が軽くても、フレームごとにJavaScriptで頂点データを再生成していれば、そこがボトルネックになる。一方で、負荷を測らずに「なめらかに見えるから大丈夫」と判断するのも危うい。開発機のGPUは強力で、実際のユーザー環境を代表しないからだ。

WebGL2とWebGPUの移行をどう判断するか

WebGL2はOpenGL ES 3.0を基盤とし、現在では主要ブラウザで広く利用できる。より新しいWebGPUは、計算シェーダーや明示的なリソース管理といった利点を持ち、主要ブラウザで段階的に利用可能になりつつある。ただし、WebGPUへ移行すれば自動的に速くなるわけではない。APIが低レベルになる分、パイプラインの設計やリソースの管理は開発者の責任になり、最適化を誤れば旧来のWebGLより遅くなることもある。

現実的な判断は、対象ユーザーの環境をcaniuseなどで確認し、フォールバックの有無で決めることになる。計算シェーダーが本質的に必要でないなら、実績のあるWebGL2で組み、将来的な移行余地だけ残しておくほうが堅い場合が多い。クリエイティブコーディング環境の比較で触れるように、道具の新しさそのものは制作の質を保証しない。

モバイルGPUとサーマルスロットリング

デスクトップで安定して動く表現が、モバイルで破綻する主因のひとつがサーマルスロットリングだ。スマートフォンのGPUは、連続した高負荷で発熱すると、性能を意図的に落として温度を下げる。この挙動のために、起動直後のベンチマークで測ったフレームレートは、数分後の持続的な性能を予測しない。

設計上は、ピーク性能ではなく持続可能な負荷を基準にするのが妥当だ。全画面シェーダーの解像度をデバイス解像度より意図的に下げる、更新頻度を落とす、静止時には描画を止めるといった手段は、いずれも見た目の妥協と引き換えに熱と電力の問題を緩和する。フォントやアセットの読み込みが描画と競合する点は、Webフォントのサブセット化で扱う問題と地続きだ。

負荷の見取り図を先に持つ

ブラウザでの生成表現は、表現の自由度が高いぶん、負荷の所在が見えにくい。フラグメントシェーダーはピクセル数に、JavaScriptはフレーム予算に、モバイルは熱にそれぞれ縛られる。どこがボトルネックかは環境で変わるため、単一の最適化で解決することは少ない。作り込みに入る前に、この見取り図を持っておくことが、後戻りの少ない実装につながる。