この質問は、Buffer.put() と Android OpenGL でパフォーマンスの問題を回避する方法に似ていますが、次の理由で質問しています。
- 少し違います - 私の問題は頂点バッファではなくテクスチャにあります
- 質問は明確ですが、ほとんどの回答は要点を逃しているようです
- 質問は3年前のもので、私の問題を解決する新しい何かがあるかもしれません
- これが問題だとは本当に驚きです...何か誤解していると思います。
とにかく、AndroidでOpenGL ES 2.0を使用しています。フレームごとに更新する必要がある大きなテクスチャ (1024x1024 など) があります。このAFAIKを回避する方法はありません.テクスチャの内容は本質的にビデオです.
問題は、OpenGL への Android Java インターフェイスが、配列ではなく java.nio.Buffer オブジェクトを使用していることです。具体的には、の最後のパラメーター
public static void GLES20.glTexImage2D (int target, int level, int internalformat, int width, int height, int border, int format, int type, Buffer pixels)
byte[]またはではなくバッファint[]です。
そのため、(フレームごとに) テクスチャのコンテンツを int[] に直接glTexImage2D生成してから に渡すのではなく、コンテンツを int[] に生成してから、巨大な配列全体に対して IntBuffer.put() を呼び出す必要があります。 . Traceview と System.nanoTime() への呼び出しは、驚くことではありませんが、これが多くの CPU を消費することを示しています。
これをどのように回避しますか？IntBuffer.array() を使用してコンテンツを配列として取得しようとしましたが、
- で割り当てられたバッファの
array()呼び出しは成功しませんIntBuffer.allocateDirect() - 呼び出しは、
glTexImage2D()割り当てられたバッファーに対しては機能しませんIntBuffer.allocate()
私が考えることができる他のこと：
- ネイティブ コードから呼び出し
glTexImage2Dます。これは、Android GL ネイティブ コード インターフェースの問題ではないと思います。 - 別のスレッドで作業を行います。しかし、これがテクスチャ コンテンツを生成するスレッドと glTexImage2D を呼び出す GL スレッドとの間で競合の問題を引き起こすかどうかはわかりません。とにかく、論理的に必要でない場合でも、メモリをコピーするには余分な CPU サイクルが必要です。
GLES20.glTexImage2D のバージョンが Buffer の代わりに int[] またはその他の配列型を取っただけであれば、これは問題にならないようです。