Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Graphics/Discussion/OpenGL ES/Bug in the glCopyTexImage2D() implementation/List of Posts
Forum Topic - Bug in the glCopyTexImage2D() implementation: (3 Items)
   
Update
Mike Gorchak
05/27/2009 1:11 AM
post30106
Bug in the glCopyTexImage2D() implementation   
As far as I understand glCopyTexImage2D() is implemented always using software fallback only, so problem affects all 3D 
drivers, not only devg-extreme2.

I'm creating texture as: 

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 128, 128,  0, GL_RGBA, GL_UNSIGNED_BYTE, data);

texture data is set to 0x00 as the initial state.

Then color buffer content (in monochromatic form) is copied to this texture via:

glCopyTexImage2D(GL_TEXTURE_2D, 0, GL_LUMINANCE, 0, 0, 128, 128, 0);

When color buffer is set to 565 format all works fine, but in case of current color buffer is in 8888 format (maybe 888 
too - I can't check) copied texture looks shrinked twice by horizontal resolution.

If GL_LUMINANCE is replaced with GL_RGBA in glCopyTexImage2D() function call - all works fine with any color buffer 
format.
Etienne Belanger(deleted)
05/27/2009 8:42 AM
post30125
Re: Bug in the glCopyTexImage2D() implementation   
It is true that the copying of image data is mostly done in software, but each driver may have its own transfer routines
. I am not 100% sure if this problem is common to all drivers or devg-extreme2 only. However, it sure sounds like there 
is a problem.

One thing, though. Your initial call to glTexImage2D defines an image of size 128 x 128 for level 0 of the currently 
bound texture with an RGBA format. The subsequent call to glCopyTexImage2D makes level 0 (I assume of the same texture) 
to be a 128 x 128 image with LUMINANCE format. Because the formats don't match, the driver will have to free the memory 
used by the first image data specification and allocate memory for this new image data.

If you are not going to use the texture until glCopyTexImage2D is called, I would just drop the first glTexImage2D. If 
the texture is used prior to the glCopyTexImage2D, you could try to specify the first image with a LUMINANCE 
internalformat. Because the internal formats match, the driver won't have to reallocate memory when you do your 
glCopyTexImage2D. It might even make your problem go away because I suspect the problem is related to the difference in 
internal formats between image specifications.
Mike Gorchak
05/27/2009 2:03 PM
post30167
Re: Bug in the glCopyTexImage2D() implementation   
> If you are not going to use the texture until glCopyTexImage2D is called, I 
> would just drop the first glTexImage2D. If the texture is used prior to the 
> glCopyTexImage2D, you could try to specify the first image with a LUMINANCE 
> internalformat. Because the internal formats match, the driver won't have to 
> reallocate memory when you do your glCopyTexImage2D. It might even make your 
> problem go away because I suspect the problem is related to the difference in 
> internal formats between image specifications.

I use the texture before glCopyTexImage2D(), but anyway changing GL_LUMINANCE to GL_RGBA helps me. GL_LUMINANCE is used 
in the first case because output for "render to texture" is monochromatic itself.

I hope this bug with conversion will be fixed soon. Etienne, I'm sorry to remind you, but maybe you'll answer my other 
questions in the OpenGL ES forum, which have remained unanswered.

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems