OpenGL texture mapping

[Pradeep]

Hi,

In our app we are decoding video frames and then rendering using
OpenGL in NDK. For rendering we are using TexSubImage2D() API to
copy data from decode frames which are in RGB16 bit format.

However texture loading is very slow esp on Nexus one.

In 1.0 ES texture mapping was the only way to draw images, in 2.0 ES
is there any more efficient way of doing this ?

Regards,
Pradeep

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Pradeep]

Hi,

In some threads I came across FrameBufferObject extension. Has anyone
tried that ?

Regards,
Pradeep

[mic _]

Frame Buffer Objects afaik are used mainly for rendering (a 3D scene) to a texture. Pixel Buffer Objects on the other hand could be useful in your situation since they allow fast uploading of texture data through DMA. I don't know if Pixel Buffer Objects are supported in OpenGL ES 2.0 though, but I suspect that Khronos has some kind of documentation that states what's supported and what isn't.

/Michael

[Eong]

Hi,
I think you should just give up the TexSubImage2D functions with
full screen drawing. I found all the phones with snapDragon chips are
slow on these TexSubImage2D functions. Nobody could really tell you
the reason here, they will just ask you to avoid this.

[David Turner]

On Sun, May 23, 2010 at 4:32 AM, Eong <eong...@gmail.com> wrote:

Hi,
 I think you should just give up the TexSubImage2D functions with
full screen drawing. I found all the phones with snapDragon chips are
slow on these TexSubImage2D functions. Nobody could really tell you
the reason here, they will just ask you to avoid this.

The reason is that GPUs are absolutely not optimized to transfer texture buffers back to main memory.

Instead, they are designed to be able to write into these buffers, then send them directly to the final

display (which may, or may not be directly addressable by the application CPU).