Hi,
I’m working on a piece of code that displays a grayscale image, tiled into square textures. For a 2.5 MB image, when the texture size is 256x256, it runs smooth. But when I lower the texture size to 32x32, it takes over 1.5 seconds to render the first time. In the first case, I have 45 textures, in the second 2880, but the overall pixel data size is the same. After the first frame, the rendering of the same 32x32 textures is almost instant. Please give me some ideas to sort out this problem.
I’m not using TEXTURE_PROXY, cause I don’t know how (the call to glTexImage2D is supposed to have NULL as the pixel data pointer - when using the proxy, but how does one specify the desired pixel data?).
Thank you.
I forgot to mention my system:
Barton 1.83, GF4Ti 4200, 64MB, AGP 4x, Win2k, drivers 52.16.
There is significant overhead involved in setting up a new texture object. If you call TexImage2D() 2880 times in a frame, I’m not surprised that it takes a while to allocate space for those textures.
I’m assuming that you’re holding on to these 2880 textures and just re-use them for future frames, which is why it’s faster after the first frame.
My suggestion is to keep the number of API calls down; if you can make do with 256x256 textures, that’s likely to perform much better.
You don’t specify data to a texture proxy. The point is just to determine if a texutre with the specified parameters could be created. The data is irrelevant in that case. Either create texture objects in advance for each of you texture tiles, or update your texture with TexSubImage2D.
>>>For a 2.5 MB image, when the texture size is 256x256, it runs smooth. But when I lower the texture size to 32x32, it takes over 1.5 seconds to render the first time. In the first case, I have 45 textures, in the second 2880, but the overall pixel data size is the same. After the first frame, the rendering of the same 32x32 textures is almost instant. <<<
That’s nice, but this is just the behavior of your implementation.
In general, you can assume that less texture switches are better. Some people out there merge multiple textures into one as a means to optimize.
There is of course a problem here when doing mipmapping.
I’m talking about run time performance here.
Hi,
Thank you for the answers.
I’m not creating the textures each frame (this is planned for later). Here are the code lines for the display:
glEnable( GL_TEXTURE_2D ) ;
for( j=0; j< tiley1; j++ ){
for( i=0; i< tilex1; i++ ){
// tiley1 and tilex1 are the texture-tiles vertically and horizontally
glBindTexture( GL_TEXTURE_2D, texname[j * tilex1 + i] ) ; // bind to current texture object
glBegin( GL_QUADS ) ;
glTexCoord2f( 0.0, 0.0 ) ;
glVertex2f( texcorn[( j * tilex1 + i ) * 8], texcorn[( j * tilex1 + i ) * 8 + 1] ) ;
glTexCoord2f( 0.0, 1.0 ) ;
glVertex2f( texcorn[( j * tilex1 + i ) * 8 + 2], texcorn[( j * tilex1 + i ) * 8 + 3] ) ;
glTexCoord2f( 1.0, 1.0 ) ;
glVertex2f( texcorn[( j * tilex1 + i ) * 8 + 4], texcorn[( j * tilex1 + i ) * 8 + 5] ) ;
glTexCoord2f( 1.0, 0.0 ) ;
glVertex2f( texcorn[( j * tilex1 + i ) * 8 + 6], texcorn[( j * tilex1 + i ) * 8 + 7] ) ;
glEnd() ;
}
}
glFlush() ;
glDisable( GL_TEXTURE_2D ) ;
I think that glBindTexture is causing the unexplainable delay for the first displayed frame. But I have to call it, otherwise the current texture would be not properly defined.
Anyway, for dynamic textures I’m going to use glTexSubImage2D (still have to learn to use it).
Hi,
I tried different formats in the glTexImage2D. Initially I used GL_LUMINANCE, but by using GL_RGBA the first frame performance improved by only 10%.
I even provided the pixel data as GL_RGBA with GL_FLOAT, which meant that the initial 2.5MB became 40MB (and should make further convertion unnecessary), but there was no improvement.
I think that at the first frame the driver uploads the texture data to video memory, by converting it to the internal format. For some reason, when the texture sizes are small, the driver does this very slow (I mean it sucks - maybe this could be a driver bug?).
I even provided the pixel data as GL_RGBA with GL_FLOAT, which meant that the initial 2.5MB became 40MB (and should make further convertion unnecessary),
What makes you say that?
The ideal format for most cards on little-endian hardware (such as IA-32 PCs) is GL_BGRA with GL_UNSIGNED_BYTE.
Hi,
According to the SDK dox I have, the internal format (for glTexImage2D) can’t be GL_BGRA (or GL_BGRA_EXT), and the pixel format can be GL_BGRA_EXT. The dox say that the pixel data is converted to a floating point RGBA and adjusted as specified by the glPixelTransfer settings. I was hoping that providing floating point pixel data would skip the conversion by the driver, but it made no significant difference. So the pixel format is not the bottleneck here.
Anyway, for dynamic textures I’m going to use TEXTURE_RECTANGLE, that I just tested, and seems to be supported by ATI too.