FYI - CopyTexImage2D is a pipeline stall so you will want to set up
your rendering order to account for that.  I'm not sure how to
optimize but I would try having it be as near to last as possible to
start with.
Thanks for the recommendation. In fact, I'm using it as the very last function in the rendering sequence. The effect on the performance is quite noticeable: the framerate goes from 60 down to 20 when doing copying a 256x512 texture.

I don't know how to get the SubImage function to work.  As far as I
understand, you must start with an allocated texture space using
TexImage2D and then and only then after that can you use
SubTexImage2D.  Please correct me if I'm wrong.
I have a suspicion as for the reason why CopyTexSubImage2D doesn't work. First of all, CopyTexImage2D only accepts GL_RGB as the internal format. GL_RGBA won't work, which seems to indicate that only RGB textures can be used as destination. I don't know the reason for this. Now, if you read the documentation for CopyTexSubImage2D:

"glCopyTexSubImage2D requires that the internal format of the currently bound texture is such that color buffer components can be dropped during conversion to the internal format, but new components cannot be added. For example, an RGB color buffer can be used to create LUMINANCE or RGB textures, but not ALPHA, LUMINANCE_ALPHA or RGBA textures."

Since the color buffer seems to provide only RGB components, according to what we observed with CopyTexSubImage2D, then we should bound an RGB texture to use with CopyTexSubImage2D. But RGB textures allocated with TexImage2D are not "functional" at all. Every time I try to render an RGB texture, I get just a white rectangle irrespective of the color buffer I use to initialize the texture.

Robert Green wrote:
Great!  I'm glad you got it to work.




I'd like to recommend checking for the FrameBufferObject (FBO)
extension and using that instead of this function when available.  I
think all of the ES2 chips support it.  It's much faster, but you'll
need to fallback to this when it's not supported.

On Apr 18, 12:30 am, Andres Colubri <[email protected]> wrote:
I finally got glCopyTexImage2D t work, using a power-of-two texture as
you suggested, and GL_RGB as internal format passed to glCopyTexImage2D
(the internal format of the texture is GL_RGBA).

glCopyTexSubImage2D doesn't seem to work though. As far as I understand
from reading the OpenGL ES documentation, this call:

glCopyTexSubImage2D(GL10.GL_TEXTURE_2D, 0, 0, 0, 0, 0, w, h);

should be equivalent to:

glCopyTexImage2D(GL10.GL_TEXTURE_2D, 0, GL11.GL_RGB, 0,0, w, h, 0)

if the internal format of the bound texture is RGB. Am I correct?

Thanks for the feedback.





Robert Green wrote:
Have you tried copying it to a power of 2 texture instead of the
viewport dimensions?  I'd test with 512x256 and see if that works.
On Apr 16, 10:22 pm, Andres Colubri <[email protected]> wrote:
Any updates on this one? I have been trying to copy the contents of the
back buffer into an opengl texture, but without success. I'm using the
same method mentioned in the first post of this thread:
gl.glCopyTexImage2D(GL10.GL_TEXTURE_2D, 0, GL11.GL_RGB, 0,0, w, h, 0); where w and h are the current width and height of the screen,
respectively. This works fine on the emulator, but it returns garbage
back into the texture on the actual device.
The phone is a Nexus One.
On Dec 11 2009, 11:56 pm, scott19_68 <[email protected]> wrote:
 > Works for me on my HTC Hero - I too could only use RGB and not RGBA.
 > Emulator flips the textures upside down though...
> Does anyone else have more information regarding other phones? I have
 > an app on the app store that uses this method and I am suspecting that
 > it does not work for all current phones.  I get really useful comments
 > like 'Does not work on Tattoo - nuff said'...
> Not sure if the forum rules prevent me from mentioning my app so PM me
 > if you'd like to help out and test - I'd definitely appreciate it very
 > much and would be willing to help you out in return regarding OpenGL
 > development questions...
> On Nov 21, 4:45 pm, Ben Gotow <[email protected]> wrote: > > Hey everyone, > > I'm porting anOpenGLapp from the iPhone to Android, and I need to
 > > renderOpenGLcontent to a texture. Since framebuffers are not
 > > available inOpenGL1.0 and the DROID is the only Android phone to
 > > support the framebuffer extension, I'm trying to draw usingOpenGLand
 > > then copy the result into a texture usingglCopyTexImage2D. However,
 > > my initial findings are not good:
> > 1.glCopyTexImage2Dworks in the Android emulator (OS v. 1.5), but
 > > only with GL10.GL_RGB, not GL_RGBA. If you try to copy the alpha data
 > > from the scene into the texture, you just get a completely white
 > > texture.
> > 2.glCopyTexImage2Ddoesn't seem to work _at all_ on the Android G1.
 > > It does not throw an UnsupportedOperationException but after calling
 > > it, the texture is completely white.
> > Has anyone successfully usedglCopyTexImage2Don an actual device? If
 > > so, could you please post a bit of the code you're using? I suspect it
 > > works only with specific settings, if at all. Right now, I'm calling
 > > it like this:
> > gl.glCopyTexImage2D(GL10.GL_TEXTURE_2D, 0, GL11.GL_RGBA, 0,0, 256,
 > > 256, 0);
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group 
athttp://groups.google.com/group/android-developers?hl=en
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group 
athttp://groups.google.com/group/android-developers?hl=en


--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to