日本語

English

日本語

English

外観

ベンチマーク ​

ここに載せている数値はすべて実測です。計測方法と生データも公開しているので、自分のハードウェアで確かめられます。

レンダラー：spryte 対 PixiJS ​

debuff はスタンドアロンのレンダラー spryte で描画しています。比較では、どのレンダラーにも同じ決定的シミュレーションと同じ 16×16 のテクスチャを使います。各フレームはシミュレーションから GPU の処理完了までを計測するので、vsync でコストが隠れることはありません。結果はすべて、交互に実行した3ラウンドの中央値です。計測の前に、ピクセル一致チェックで、すべてのレンダラーが 2,000 スプライトと 50,000 スプライトで同じシーンを描くことを確認します。描画面積が 0.5% を超えて違うレンダラーがあるか、スプライトの内側のピクセルが違えば、その時点で失敗です。

60 fps のスプライト数：spryte draw.sprites 80万、PixiJS ParticleContainer 20万、spryte draw.sprite 10万、PixiJS Sprite 5万、Canvas 2D 5千

同条件での比較 ​

ワークロードsprytePixiJS 8spryte は
動的パーティクル（位置、スケール、回転、色、アルファがパーティクルごとに変化）、20万7.7 ms（draw.sprites）28.9 ms（ParticleContainer、これらのプロパティを dynamic に設定）3.8倍速い
回転、スケール、色、アルファが変化するスプライト、テクスチャ4種、5万9.8 ms（draw.sprite）32.3 ms（Sprite）3.3倍速い
Bunnymark（位置のみ）、5万5.8 ms（draw.sprite）16.4 ms（Sprite）2.8倍速い
Bunnymark、一括、20万4.4 ms（draw.sprites）8.9 ms（ParticleContainer）2.0倍速い

60 fps で描けるスプライトの最大数 ​

sprytePixiJS 8
一括、位置のみ800,000200,000（ParticleContainer）
動的パーティクル400,000100,000（ParticleContainer）
スプライトごとに1回呼び出し、bunnymark100,00050,000（Sprite）
スプライトごとに1回呼び出し、混合50,00020,000（Sprite）
素の Canvas 2D drawImage5,000

debuff の Game が spryte に上乗せするコストは計測できないほど小さいです（5万で 6.0 ms 対 5.8 ms、誤差の範囲）。

2026-10-19 に計測。環境は Windows 11、Chrome 155、NVIDIA RTX 5060 Laptop GPU（ANGLE / Direct3D 11）、AMD Ryzen 7 260、AC 電源、電源プラン Turbo です。バージョンは spryte 0.1.0、PixiJS 8.22.0 です。最小〜最大の幅を含む全結果は spryte benchmarks にあります。

公平に読むために ​

  • マシン1台、ブラウザ1種類。 スマホ、Safari、Firefox の結果はまだありません。spryte の優位は主に CPU と転送帯域によるものなので、フィルレートが律速になるデバイスでは差が縮まるかもしれません。指標としては比率を見てください。
  • 専用同士、汎用同士。 draw.sprites と ParticleContainer はどちらも一括描画用の経路で、draw.sprite と Sprite は普段使いの経路です。両方の組み合わせを載せています。
  • 回転した縁以外は同じピクセル。 カバー率はどこでも 99.8〜100%、スプライト内側の差は 0% です。回転のあるシーンでは描画ピクセルの 8.6〜12.7% が異なりますが、すべて縁の部分です。PixiJS の roundPixels は回転した角をスナップし、spryte はしないためです。内側のチェック自体も検証済みで、わざと PixiJS の色指定を間違えると 0% から 22% に跳ね上がります。
  • あえて攻撃してみました。 比較が spryte 寄りになっていないかを、敵対的なレビューで検証しました。その結果、「動的」シーンのスケール、色、アルファが一定で、PixiJS 側は static にできたことが判明しました。現在は時間とともに変化するようにしてあり、パーティクルの結果は 4.2倍から 3.8倍に下がりました。PixiJS の WebGPU レンダラー（ここでは遅い）、roundPixels、アトラス（PixiJS で約 11%、誤差の範囲）、同期、ウォームアップも確認し、公平だと判断しています。
  • 過去の数値とは比べられません。 2026-10-16 には同じノート PC で、どのレンダラーもより速く計測されました。意味があるのは同じセッション内の比率だけです。
  • Canvas 2D フォールバックは WebGL2 が使えない環境でのみ使われます。手書きの Canvas 2D より約 20% 遅く（1万スプライトで 31.9 ms 対 26.5 ms）、これは色指定とフラッシュに対応するためのコストです。

再現する ​

ベンチマークは debuff リポジトリ（bench/renderer）にあり、インストール済みの Chrome か Edge でヘッドレスに動きます。

bash
git clone https://github.com/debuffjp/debuff
cd debuff
npm install
npm run build
npm run bench:renderer                 # bunnymark
npm run bench:renderer -- mixed        # または particles

結果は GPU、ブラウザ、CPU、電源状態とともに bench/renderer/results/ に書き出されます。PARITY_DUMP=1 を付けると一致チェック用のフレームも保存されるので、自分で見比べられます。ほかのデバイスでの結果、特にスマホの結果は、プルリクエストで大歓迎です。設計判断の記録は ADR 0013 にあります。

ブラウザで試す ​

プリンコのデモには stress test ボタンがあります。デバイスが 60 fps を保てる限りスプライトを追加し続け、最後に耐えた数を表示します。

サイズ ​

spryte 単体の起動時の JavaScript は 10.1 kB です。ドキュメントどおりに組んだ PixiJS 8 アプリは 87.8 kB なので、約9分の1になります（brotli、同じスプライト1枚のシーンを Vite の本番ビルドで比較。計測ハーネス）。

npm create debuff のスターターゲームは、ランタイム、入力、オーディオ、juice、ゲーム本体まですべて含めて brotli で約 19 kB です。debuff build はすべてのファイルの raw、gzip、brotli のサイズを表示し、開発用ツールがビルドに紛れ込むと失敗します。

最終更新: