OpenGLの変換スタックを使用するか、手動で変換を適用する方が効率的です。
グラフィックパイプラインの状態遷移の数を最小限に抑える必要があるとよく耳にします。翻訳マトリックスのプッシュとポップは大きな変化のようです。ただし、グラフィックスカードは、並列実行ハードウェアを使用して頂点を一括乗算することで、パイプラインの問題を補う以上のことができるのではないかと思います。
私の特定のケース。スプライトシートにフォントをレンダリングしました。各文字または文字列の座標が計算され、頂点バッファーに追加されます。次に、そのストリングを移動する必要があります。頂点バッファーを反復処理して、各頂点を手動で調整するか、一時的に新しい変換行列をプッシュする方が良いでしょうか？
回答:
仕様の最新バージョン（3.3および4.x）ではマトリックススタックがなくなっており、手動で変換マトリックスを追跡する必要があることは私の理解です。これはモバイル（ES）仕様にも当てはまると思います。
手作業で行列を処理する一貫した方法を探している場合は、GLMに興味があるかもしれません。これは、GLSL仕様に基づいてモデル化された非常にきちんとした数学ライブラリー（マトリックス変換を含む）なので、OpenGLコードを処理するときは、1組の数学ルーチンを頭に置いておくだけで済みます。
スタックはここではあまり最適ではありません-複雑なドライバーレベルの状態変化を誘発してはならないため、プッシュとポップが高価だったためではありません（レンダーコマンドが発行されるまで、マトリックスはカードに送信されません）なので、通常はAPIでのすべてのCPU側の操作です。
スタックの問題は、プッシュできる距離に制限があることです。これは、glGet *で取得できるパラメーターの1つだと思います。マトリックス数学を書いていない、またはできない、または望まない場合を除いて、スタックを使用しても大きな利点はありません。自分で行うことをお勧めします。
スタック関数の状態が最新のGLでどのようになっているのかわかりません。それらも非推奨/削除されたと思いますが、しばらくの間実際にGLを使用する必要がなかったため、最新の状態に保ちませんでした。
他の人が指摘したように、マトリックススタックは間もなくリリースされます。これは、代替案を調査するための良い理由です。
私のプロジェクトの1つでは、OpenGLのマトリックス演算を使用してマトリックスを計算しましたが、最終的にはglGet関数を使用してマトリックスをフェッチし直す必要があったため、OpenGLの独自の関数がサポートしていないマトリックスでいくつかの操作を実行できました。パフォーマンスはひどいものでした、そして私は単一のglGet関数への損失を追跡しました。マトリックス演算が実際にGPUで何らかの方法で実行され、glGetを使用するとパイプラインのフラッシュなどが発生する可能性があります。
理由が何であれ、私は行列演算をCML、構成可能な数学ライブラリに置き換え、パフォーマンスが劇的に向上しました。OpenGLマトリックス操作のパフォーマンスメトリックに縛られなくなっただけでなく、CMLにはOpenGLがサポートしていない大量の操作も含まれていました。
そして、行列のスタックの実装は、STLベクトルなどを使用して非常に簡単です。
経験のレベルはわかりませんが、手作業で行うことをお勧めします。これを行う方法を学ぶにはより多くの努力が必要かもしれませんが、マトリックスが何をしているかを理解し、自分でマトリックスを操作できることは非常に有益です。また、異なる順序で行列を適用するときに発生する可能性のある問題（たとえば、スケーリングと回転）をより認識しやすくなります。私は何時間もかけて、奇妙なレンダー「バグ」を理解するために何時間も費やしてから、各操作が何をしているかを徹底的に研究することに時間を費やす方がよいと判断しました。投資する価値があります。
特定の問題に対処するには、頂点に変換を適用するのが最も簡単な方法のようですが、行列の演算の順序に注意してください。