メインスレッドの呪縛を解く：OffscreenCanvasで実現する「真の」非同期レンダリング
ブラウザのメインスレッドは、常に「忙しすぎる」運命にある。JavaScriptの実行、スタイル計算、レイアウト、ペイント……。これら全てが単一のイベントループで回っている限り、重い計算や複雑なレンダリングが差し込まれた瞬間に、UIはフリーズする。いわゆる「ジャンク（Jank）」だ。
上級エンジニアである君なら、`requestAnimationFrame`で必死にタスクを分割したり、`requestIdleCallback`で間を縫うように処理を詰め込んだ経験があるだろう。しかし、本質的な解決策はそこにはない。「描画処理をメインスレッドから追い出すこと」。これこそが、アーキテクチャの観点から見た唯一無二の解だ。
1. ブラウザエンジンが隠し持つ「オフスクリーン」の深淵
`OffscreenCanvas`は、ただの「Workerで使えるCanvas」ではない。これは、DOMの制約からグラフィックスコンテキストを解放するための強力なAPIだ。
通常、`HTMLCanvasElement`はDOMツリーの一部であり、その描画コンテキストを取得して操作するたびに、ブラウザのレンダリングパイプラインと同期を取る必要がある。しかし、`transferControlToOffscreen()`を呼び出した瞬間、そのCanvasの制御権はメインスレッドから切り離され、Workerスレッドへと移譲される。
ここで重要なのは、ブラウザの合成レイヤー（Compositor Layer）がどう動くかだ。Worker側で描画されたバッファは、メインスレッドを介さず、GPUへと直接送られるパスを通る。これにより、JavaScriptの実行負荷がどれだけ高まろうと、60fps（あるいはそれ以上）の描画更新を維持できる。これが、堅牢なWebアプリケーションの最低条件である。
2. 実装の作法：Workerとの橋渡し
まずは、メインスレッドからWorkerへCanvasを渡すコードを見てほしい。
// main.js
const canvas = document.querySelector(‘#render-canvas’);
// transferControlToOffscreenを呼ぶと、元のcanvasは「制御不能」になる点に注意
const offscreen = canvas.transferControlToOffscreen();
const worker = new Worker(‘render-worker.js’);
// 第2引数に転送対象を指定（構造化複製アルゴリズムによる転送）
worker.postMessage({ canvas }, [canvas]);
Worker側の実装は、まるでメインスレッドで描画しているかのようにシンプルだ。
// render-worker.js
let ctx;
self.onmessage = (e) => {
const { canvas } = e.data;
ctx = canvas.getContext(‘2d’); // あるいは ‘webgl’, ‘webgpu’
renderLoop();
};
function renderLoop() {
// メインスレッドのUIブロックとは無縁の世界で描画を行う
ctx.fillStyle = ‘rgba(0, 0, 0, 0.1)’;
ctx.fillRect(0, 0, 1000, 1000);
// 描画負荷がどれだけ高くても、UIスレッドは滑らかに保たれる
requestAnimationFrame(renderLoop);
}
3. アーキテクチャの陥陷と回避策
この技術を使う際、単に「Workerに投げれば速い」と考えるのは早計だ。実務レベルで必ず直面する壁がいくつかある。
A. メモリリークと転送の代償
`transferControlToOffscreen`を行った後、メインスレッド側のCanvasオブジェクトは「抜け殻」になる。誤ってメインスレッドで描画コンテキストを取得しようとするとエラーが発生する。また、Worker側での描画オブジェクトの生成・破棄の頻度には注意が必要だ。大量のテクスチャやバッファを生成し続けると、ガベージコレクション（GC）が頻発し、結果としてパフォーマンスが低下する。
B. 非同期の競合と状態同期
Canvasのサイズ変更（リサイズ）は、メインスレッドとWorkerの両方に影響を及ぼす。メインスレッドでブラウザウィンドウがリサイズされた際、Workerへ`width`や`height`の変更を伝える必要があるが、この通知は非同期だ。
回避策: メインスレッド側で`ResizeObserver`を使い、変更をWorkerに同期する際、必ず`requestAnimationFrame`のサイクルに合わせて更新をかけること。そうしないと、描画サイズとCSSのサイズが不一致を起こし、映像がボケる現象が発生する。
C. フォントと外部アセットのロード
Workerは`document`にアクセスできない。つまり、CSSで定義されたフォントや、DOM経由の画像ロードができない。これらは、`ImageBitmap`や`Blob`としてメインスレッドから転送するか、Worker内での`fetch`が必要になる。特に`createImageBitmap`は、メインスレッドの負荷を下げつつWorkerにデータを渡すための「神API」なので、必ず使いこなしてほしい。
結論：ブラウザを「アプリケーション」たらしめるために
`OffscreenCanvas`を導入するということは、ブラウザという「ドキュメント閲覧ソフト」を「OSのようなグラフィックスプラットフォーム」へと昇華させる作業に他ならない。
複雑なデータビジュアライゼーション、ゲームエンジン、あるいは高頻度で更新されるUIパーツ。これらを実装する際、メインスレッドを保護することは、ユーザーに対する誠実さそのものだ。
君のアプリケーションが、どれだけ重厚な計算を裏で回していようと、ユーザーのスクロール一つが引っかかってはならない。ブラウザのレンダリングパイプラインを理解し、スレッドの境界を賢くコントロールする。その先にこそ、真に堅牢なWebアプリケーションの世界が待っている。
さあ、メインスレッドを解放しよう。コードは嘘をつかない。
コメント