アプリの UI 用にシーン グラフ ベースのレンダリング システムを構築しました (興味がある場合はhttp://audulus.comを参照してください)。アプリの UI は手続き型で、その多くはアニメーション化されています。レンダリング済みの画像はほとんどありません。
現在、mipmap されたテクスチャ内のドローアブルの不変のグループをキャッシュします。UI はズーム可能であるため、ミップマップを使用します。全体として、これによりパフォーマンスが大幅に向上しましたが、いくつかの欠点があります。
ミップマップの作成 (glGenerateMipmap による) には時間がかかり、UI の一部がアニメーションから静的になるとフレーム レートが低下します。
テクスチャ キャッシュされたジオメトリとそうでないジオメトリの間の視覚的な違いにより、わずかなちらつきが発生します。(私のパス レンダリング コードをもっと賢くすることでこれを回避できるかもしれませんが、難しいようです)
すべてのテクスチャのメモリ使用量 (オフスクリーン テクスチャをダンプできますが、問題 1 を悪化させます)
私が考えたいくつかの代替アプローチ：
テクスチャ キャッシングの代わりに、静的パスをより大きなパスに結合します。私のパスはすでに VBO/VAO ベースですが、これにより GL 呼び出しの数を減らすことができます。(テクスチャ キャッシングをオフにすると、パフォーマンスは主に CPU バウンドになります)。メモリ使用量に大きな勝利。このアプローチの主な問題は、パス レンダリング シェーダーが複雑になること (glDrawArrays への 1 回の呼び出しで異なる属性を持つパスを処理する必要があるため)、他のプリミティブ (テキストなど) のキャッシュを処理しないこと、および GPU への負担が増えることです。単にテクスチャをレンダリングするだけではありません。
引き続きテクスチャを使用しますが、ミップマッピングは避けてください。UI がズームされると、テクスチャのサイズが変更される可能性があります (ただし、ズーム中に UI 全体を再レンダリングするのはコストがかかりすぎるため、延期する必要がある場合があります)。オフスクリーン ジオメトリのテクスチャを削除します。もちろん欠点は、UI ズーム中のテクスチャの拡大/縮小が不十分なことです。
アップデート
(2) やってみました。テクスチャのサイズ変更は非常に遅いため、UI がズーム中にサイズを変更しないようにします。これはかなりうまく機能しますが、ズームを小さく始めると倍率がひどいように見えます。
一部のモジュールは、アニメーションとしてタグ付けされているため、テクスチャがキャッシュされていないことに注意してください。
更新 2
アプローチ 1 に取り組み始めたので、テクスチャ キャッシュを無効にしました。
私は CPU バウンドですが、事実上すべての GPU 側の負荷はパス アンチエイリアシング フラグメント シェーダーから来ています。装着時の性能はこんな感じ。
そしてそれをオフにします：
したがって、それをさらに最適化することは、GPU 側にとって大きなメリットとなります。私はそれを捨てて 4x スーパーサンプリングを試してみましたが、それはゴミのように見え、パス レンダリング シェーダーの作業にかなりの時間を費やした理由を思い出しました。
