   with mipmaps 800 FPS, no  mipmaps 80 FPS
  Hi everyone,I am working on a texture font class and to date have been using a default TGA loading routine that created a texture with mipmaps when it loaded the image file. I have been getting 800FPS throughout development. However, when I added a conditional around the mipmap calls and chose not to generate them, the framerate dropped ten fold to just 80 FPS, and drops another 20FPS for every new font I render. I'm down to 7FPS with 5 fonts on the screen and the program is sluggish. Choose to enable mipmap generation, and it's back to 800FPS with five fonts. Very odd. I've probably been staring at the code too much and the issue is right in front of me. Anyone here see the error in my ways with this? // Create our OpenGL texture from image just loadedbool FTGAImage::CreateTexture(){// generate a texture objectglGenTextures(1, &texID);glBindTexture(GL_TEXTURE_2D, texID);PrintDebug("Creating texture ID : %d for image %s\n",texID,filename.c_str());// set filteringglTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, filter);glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, filter);// set texture repeating or clampingif (doClamp){glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);} else {glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);}// create OpenGL textureglTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL);glTexImage2D(GL_TEXTURE_2D, 0, RGBtype, width, height, 0, RGBtype, GL_UNSIGNED_BYTE, imageData);// generate mipmaps if requestedif (doMipMaps){// assign the mip map levels and texture infoglTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_NEAREST);// build mipmapsgluBuild2DMipmaps(GL_TEXTURE_2D, RGBtype, width, height, RGBtype, GL_UNSIGNED_BYTE, imageData);}// remove image data from memory now texture has been createdif (delAfterTexCreate){if (imageData != NULL) {PrintDebug("Releasing image data from memory in texture create for %s\n",filename.c_str());delete imageData;imageData = NULL;}}// all okisCreated=true;return isCreated;}
  Usually I would have guessed that a) your texture dimensions aren't power of two (which sucks and is usually sloooow) and b) you are using very large textures that are radically scaled down, resulting in large jumps between texture reads and making the texture cache useless. Both would be fixed by mipmaps, because a) glu resizes the image to power of two when building mipmaps and b) within a smaller mipmap the texture accesses should be closer together and make better use of the cache.   ;  I'd go with Trienco on the texture jumps. If you are using a massive texture but only rendering a small quad, the hardware has to jump long distances to find the next pixel, if you are using Mip-Maps the texture jumps are a lot smaller, making your code faster.   ;  That is odd.  I can't think of anything else it might be besides what Trienco and theZapper say.  I do notice one oddity in your code though.  You are calling glTexImage2D. and then if you're using mipmaps calling gluBuild2DMipmaps.  gluBuild2DMipmaps creates the entire mipmap chain, including level 0 (the level that your glTexImage2D call is creating).  This means you are creating level 0 twice.  It shouldn't be causing any problems but it is not very efficient to do something that is just going to be redone again.Actually now that I think about it, I'm leaning much more towards the non-power-of-two texture idea (Trienco's (a)).  The reason it works so well with mipmaps is because the GLU function for building mipmaps resizes textures if they are not a power of two.  So when you are using mipmapping, you have a normal power-of-two sized texture (gluBuild2DMipmaps overwrites the level 0 image you just created).   ;  You guys are all spot on. I had introduced a couple of new fonts that were not exactly a power of two. Brilliant. Thanks for the help! Much appreciated. I have fixed up the code to also make one call to generate the texture to improve efficiency, as Kalidor points out.Quite amazing the slowdown when not using a power of two texture.F451[Edited by - Fahrenheit451 on December 16, 2005 6:38:44 PM];  You should see the slow down of non 4byte aligned vertex data on my ATI. It's fascinating how a simple cube can drop from 1200fps to 0.0<many zeroes><something>fps just because you're using bytes instead of wasting tons of not required memory for floats (just in case you ever think "hey, a 256x256 grid is fine for my simple levels, I don't need huge floating point positions")   