WebGL は本当に遅いです。
フレームあたり 100 スプライト - わかりました。
フレームあたり 1000 スプライト - 最適化が必要です。
10000 スプライト、fps ドロップダウン 40 から 20fps。
3Dは全く必要ありません。フィルター、シェーダー、ライト、その他の 3D 要素は必要ありません。PNG をレンダリングし、デバッグ用の形状 (線、棒、円) をレンダリングする機能を備えた、高速な 2D キャンバス (ピクセル スムージングなし) が必要です。PlayN エンジンから WebGL を除外して、HTML5 Canvas に切り替える可能性はありますか? (WebGL よりもはるかに高速になると思います。)
これは WebGL とは関係ありません。WebGL は高速です。また、PlayN とは関係ありません。あなたは SUV を使ってインディ 500 に出場することを求めています。SUV は、特殊なレースカーに匹敵するものではありません。ただし、未知の地形を運転し、子供をサッカーの試合に連れて行き、帰りに食料品を買う必要がある場合は、SUV の方がはるかに適しています。
あなたが説明した場合、遅さは WebGL 呼び出しでも Canvas.drawImage 呼び出しでもありません。それは、PlayN が完全なアフィン変換乗算を実行して、すべてのフレームのすべてのスプライトの現在の変換を計算するという事実です。ほとんどのゲームでは一度に画面に表示されるスプライトは 1000 未満であり、これらのスプライトを好きなように操作できる柔軟性を好むため、99% の確率でこれが必要になります。
本当に 10,000 個のスプライトが必要で、シーン グラフ エンジンをパーティクル システムとして使用しようとしているだけではない場合は、ImmediateLayerレイヤーを使用して Surface.drawImage を呼び出し、必要な位置に画像を描画し、計算を維持します。最小限に彼らの位置を決定します。