なぜブラウザでドット絵を描くのか

Canvas API の内側 — ピクセル操作の仕組み

Canvas 2DコンテキストのgetImageData()は、指定領域のピクセルデータをImageDataオブジェクトとして返します。これは、各ピクセルのRGBA値が格納されたUint8ClampedArray（型付き配列）です。たとえば32x32のキャンバスなら、32 × 32 × 4 = 4,096バイトの配列になります。

この仕組みにより、C言語のようにメモリ上の画像バッファを直接操作できます。putImageData()で書き戻せば、数千ピクセルの一括変更もミリ秒単位で完了します。フィルター処理や色変換、レイヤー合成もすべてこのバイト配列操作で実現できるのです。

型付き配列（Typed Array）はJavaScriptの通常の配列と異なり、メモリ上に連続した領域を確保します。これにより、CPUのキャッシュ効率が劇的に向上し、大量のピクセル処理でもネイティブに近い速度が出ます。ブラウザの中でこのレベルの低レベル操作ができるようになったのは、HTML5以降の大きな進歩です。

レイヤー合成の仕組み

Pixnoteのマルチレイヤー機能は、各レイヤーのピクセルデータをメモリ上の配列として管理し、表示時に単一のCanvasへ合成出力する方式を採用しています。Editor Liteでは、各ピクセル位置について上位レイヤーから順にパレットインデックスの配列を走査し、最初に見つかった非透明ピクセルをImageDataに書き込みます。

この方式ではgetImageData()で取得したバイト配列に直接ピクセル値を書き込み、putImageData()で一括反映します。全ピクセルをループ処理するため一見非効率に思えますが、型付き配列のメモリ連続性とJITコンパイラの最適化により、数千ピクセル規模のドット絵キャンバスでは十分な速度で動作します。

JITコンパイラの仕組み — なぜブラウザのJSは速くなったか

初期のJavaScriptエンジンはインタプリタ方式で、コードを1行ずつ読んで実行していました。V8エンジンは、実行中のコードを分析し、頻繁に実行される「ホットパス」をネイティブの機械語に直接コンパイルします。

現在のV8は多段階のパイプラインを持っています。まずIgnition（インタプリタ）がバイトコードを素早く実行し、その間にプロファイリングデータを収集します。十分なデータが集まると、TurboFan（最適化コンパイラ）が高度に最適化された機械語を生成します。

この仕組みにより、ドット絵エディタの描画ループのように繰り返し実行されるコードは、事実上ネイティブコンパイルされたプログラムと同等の速度で動作します。「JavaScriptは遅い」というのは、もはや2000年代の話です。

3大エンジンはすべて多段階JITを採用しており、激しい性能競争（「ブラウザ戦争」の技術面）を続けています。この競争こそが、Webアプリの性能を年々向上させている原動力です。

「ブラウザ戦争」がもたらした恩恵

2008年以降、Chrome（V8）、Firefox（SpiderMonkey）、Safari（JavaScriptCore）の3大エンジンは激しい性能競争を繰り広げてきました。あるエンジンが新しい最適化手法を導入すると、他のエンジンも追随します。この競争は、Web開発者やユーザーにとって大きな恩恵をもたらしました。

Hidden Classes（オブジェクトの形状に基づく最適化）、Inline Caching（プロパティアクセスの高速化）、Escape Analysis（不要なメモリ割り当ての排除）など、各エンジンは最先端のコンパイラ技術を投入しています。これらの技術は学術研究レベルのものであり、世界最高峰のエンジニアが無料のブラウザのために最適化を続けているのは、人類のソフトウェア史上でも特筆すべきことです。

PNG出力の裏側

ドット絵をPNGとしてダウンロードする処理も、すべてブラウザ内で完結しています。canvas.toBlob()メソッドがCanvas上のピクセルデータをPNG形式にエンコードし、URL.createObjectURL()でダウンロード可能なURLを生成します。サーバーサイドの処理は一切介在しません。

PNG出力の処理にサーバー通信は一切発生しません。クラウド保存機能を使わない限り、作品データがネットワーク上を流れることはありません。描画もエクスポートもローカルで完結するため、意図しないデータ送信のリスクがないのです。

画像データはなぜ重いのか

この記事のHTMLテキスト全体は、圧縮前でもせいぜい数十KBです。一方、たった32×32ピクセルの画像でも、RGBA形式では 32 × 32 × 4バイト = 4,096バイト（4KB）。レイヤーが4枚あれば16KB。それにUndo履歴を50ステップ分保持すると、この小さなキャンバスだけで 数百KB〜数MB のメモリを消費します。64×64なら4倍、128×128なら16倍。何も工夫しなければ、ブラウザのメモリを簡単に食い潰してしまいます。

Pixnoteはこの問題に対して、メモリ、圧縮、通信、描画のあらゆる面で工夫を重ねています。

パレットインデックス方式 — 1ピクセル1バイトの世界

通常のCanvas画像データは1ピクセルにつきRGBA 4バイトを消費します。しかしドット絵は使う色数が限られている — この特性を最大限に活かすのがPixnoteの設計思想です。

Pixnoteは各レイヤーに indexMap（Uint8Array）という独自のデータ構造を持っています。各ピクセルに対して「パレットの何番目の色を使っているか」をたった1バイトで記録します。RGBA方式の4バイトに対して メモリ消費量は1/4。256×256キャンバスなら、indexMapはわずか64KBです。同じ情報をRGBAで持つと256KB。このデータはパレット色の一括変更にも使われ、全ピクセルを走査して該当色を瞬時に書き換えられます。

Undo履歴の段階的圧縮

Undo（元に戻す）機能はエディタの生命線ですが、最もメモリを消費する機能でもあります。Pixnoteはここに独自の段階的圧縮を導入しています。

まず、キャンバスサイズとレイヤー数から1ステップのデータサイズを算出し、300MBのメモリ予算内で何ステップ保持できるかを動的に計算します。小さなキャンバスなら最大50ステップ、大きなキャンバスでも最低5ステップを確保。さらに、現在の操作位置から離れた古い履歴は、生のImageDataからPNG Blobに変換してメモリ上で圧縮します。直近の数ステップだけを即時復元可能な状態で保持し、残りは圧縮状態で待機させる — CPUとメモリの最適なバランスを取っています。

保存データの徹底的な圧縮

クラウド保存やエクスポート時のデータサイズも、通信コストとストレージに直結します。Pixnoteは複数の圧縮戦略を組み合わせて、転送量を最小限に抑えています。

Differential PNG（差分PNG）— パレットで描画されたピクセルは、indexMapに色情報がすでに記録されています。保存時にPNG側の該当ピクセルを透明化し、純粋なパレット描画のレイヤーは実質的に空のPNG（約100バイト）にまで圧縮します。読み込み時はindexMapから復元するため、データの欠損はありません。

indexMapのGzip圧縮— ドット絵は同じ色が広い範囲に連続する傾向があります。この特性はGzip圧縮と極めて相性が良く、CompressionStream APIを使って 約83%の圧縮率 を達成しています。

条件付きWebP変換— PNGサイズが100KBを超える場合のみWebP形式への変換を試み、WebPの方が小さい場合にだけ採用します。闇雲にフォーマットを変換するのではなく、実際にサイズが縮む場合のみ切り替える堅実な判断です。

通信の最小化 — 送るのは変わったものだけ

画像データのネットワーク転送は、テキストのそれとは比較にならないコストがかかります。Pixnoteは「必要最小限しか送らない」を徹底しています。

SHA-256ハッシュによる重複排除— アップロード前に各データのハッシュをサーバーに問い合わせ、すでに存在するデータは送信しません。同じ画像を何度保存しても、実際にアップロードされるのは初回の1回だけです。

変更レイヤーだけを同期— 10レイヤーある作品でも、変更があったレイヤーだけをアップロードします。残り9レイヤーの再送信は不要。

インテリジェントなバッチ処理— 複数のデータを500KB以下のバッチにまとめ、HTTPリクエスト数を大幅に削減します。リクエスト1件ごとのオーバーヘッド（TLS、ヘッダー等）を考えると、この集約の効果は大きい。

描画パフォーマンスの地道な工夫

体感の「軽さ」を支えているのは、一つひとつは地味だけれど積み重なると大きな差になる最適化の数々です。

Canvas 2DコンテキストのwillReadFrequentlyフラグを有効にして、getImageData/putImageDataの頻繁な呼び出しに備え、ブラウザがGPUメモリではなくCPUメモリにピクセルデータを配置するように指示しています。ドラッグ操作中はUIの全体更新を抑制し、座標表示だけを軽量に更新。選択範囲の回転プレビューはキャッシュし、角度やサイズが変わらない限り再計算しません。選択範囲のマーチングアンツ（点線アニメーション）はrequestAnimationFrameでディスプレイのリフレッシュレートに同期し、無駄な描画を防いでいます。

余談：リソースが潤沢な時代の省エネ

ハードウェアの性能は毎年上がっています。メモリは安くなり、CPUは速くなり、通信帯域は広がり続けている。じゃあ最適化なんて気にしなくていいのかというと、実はそうでもありません。

コンピュータサイエンスに「計算量（オーダー）」という概念があります。O(n)で済むアルゴリズムをO(n²)で書いてしまうと、CPUのクロックが2倍になっても、データが2倍になれば4倍遅くなる。ムーアの法則はアルゴリズムの非効率を救ってくれません。暗号処理やハッシュ計算のように、数学的に一定の計算量が不可避な処理もあります。どんなに速いマシンでも、計算量そのものは減らせない。だから「速いマシンを使えば解決」とはならない場面が、ソフトウェアには普通にあるわけです。

もうひとつ、忘れがちなのが電力です。無駄な計算は無駄な電力消費。世界中で何億台ものデバイスが動いている時代に、ソフトウェアの効率が少し改善されるだけでもインパクトは大きい。省メモリ・省CPUなソフトウェアは、結果として省エネなソフトウェアでもあります。

リソースが潤沢な時代だからこそ、ケチケチ使っていきましょう。その方がユーザーのデバイスも快適だし、バッテリーも長持ちするし、地球にもちょっとだけ優しい。みんなで省エネ、悪くない話です。