SDL_Texture
オブジェクトはビデオ カード メモリのできるだけ近くに保存されるため、GPU によって簡単に高速化できます。サイズ変更、アルファ ブレンディング、アンチエイリアシング、およびほとんどすべての計算負荷の高い操作は、このパフォーマンスの向上によって深刻な影響を受ける可能性があります。プログラムがテクスチャでピクセルごとのロジックを実行する必要がある場合は、テクスチャを一時的にサーフェスに変換することをお勧めします。ストリーミング テクスチャを使用して回避策を達成することも可能です。
編集:この回答はかなりの注目を集めているので、私の提案を詳しく説明したいと思います。
ワークフローを使用Texture -> Surface -> Texture
してピクセルごとの操作を適用する場合は、レンダリング サイクルごとに再計算する必要がない限り、最終的なテクスチャをキャッシュしてください。このソリューションのテクスチャはSDL_TEXTUREACCESS_STATIC
フラグで作成されます。
ストリーミング テクスチャ (作成フラグはSDL_TEXTUREACCESS_STREAMING
) は、ピクセル データのソースがネットワーク、デバイス、フレーム サーバー、または SDL アプリケーションの完全な範囲を超えたその他のソースであり、ソースからのフレームのキャッシュが非効率的であることが明らかな場合に推奨されます。または動作しません。
SDL_TEXTUREACCESS_TARGET
テクスチャがフラグ付きで作成されている場合、テクスチャの上にレンダリングすることができます。これにより、描画操作のソースが他のテクスチャに制限されますが、これは最初に必要なものである可能性があります。「レンダー ターゲットとしてのテクスチャ」は、SDL2 の最新かつ最もサポートされていない機能の 1 つです。
好奇心旺盛な読者のためのオタク情報:
SDL 実装の性質上、最初の 2 つの方法はアプリケーション レベルの読み取り操作とコピー操作に依存しますが、推奨されるシナリオ向けに最適化されており、リアルタイム アプリケーションに対して十分高速です。
アプリケーション レベルからのデータのコピーは、GPU での後処理と比較すると、ほとんどの場合低速です。要件が SDL が提供できるものよりも厳しく、ロジックが外側のピクセル データ ソースに依存しない場合は、SDL サーフェスからペイントされた未加工の OpenGL テクスチャを割り当て、それらにシェーダー(GPU ロジック) を適用するのが賢明です。
シェーダーは、GPU アセンブリにコンパイルされる言語である GLSL で記述されています。ハードウェア/GPU アクセラレーションは、実際には GPU コアで並列化されたコードを指し、シェーダーを使用することは、レンダリング目的でそれを達成するための推奨される方法です。
注意!生の OpenGL テクスチャおよびシェーダーを SDL レンダリング関数および構造と組み合わせて使用すると、予期しない競合が発生したり、ライブラリによって提供される柔軟性が失われたりする可能性があります。
TLDR;
テクスチャの変更は面倒な場合がありますが、サーフェスよりもテクスチャをレンダリングして操作する方が高速です。