   glDeleteTextures - only it didn't
  I have a perculiar problem.  When using glDeleteTextures, I noticed that the textures I assumed would be gone, are still in memory and are still named.I keep an array of all the texture names, so I simply call glDeleteTextures with the number of textures and the address of the zeroth element of the array, which you would expect to remove all but the bound texture.  It didn't.  All of the textures are remaining in memory and I am able to rebind them and draw with them.Obviously something is wrong - is it glDeleteTextures at fault?  Should I be using a different method to clear the textures out?  Funny thing is, I've used glDeleteTextures before and I'm pretty positive it worked fine (although there's always a chance that I never caught the fact that it wasn't and just assumed it worked).So how is everyone else removing their textures?   
  What happens when you call glDeleteTextures() depends on the driver you are running on.There is a chance the driver could delete the infomation there and then, however what is more likely is that the texture is flagged internaly as deleted and is removed at a later time. For example, when you next request a texture ID it could return a previously deleted ID and when you upload reuse the structure/memory as required/avaible.   ;  I know that the driver rarely actually removes the data in any way other than marking it as deleted, but surely once it's been flagged as deleted, I should not be able to bind it again using the previously generated name?   ;  AFAIK, the results of binding a non-allocated texture are undefined. As was already said, it is very probable that the driver does not actually delete the VRAM data when calling glDeleteTextures(), but rather flags them as free. One might expect that binding a deleted texture would (at least) bind the default texture, but this is not required - in your case this doesn't happen.If you have time, it might be interesting to create a small demo to see the behaviour of different gfx cards / and driver combinations on this issue.   ;  I'd be curious to see what you get if you call glIsTexture() on a texture name right after you delete it. I've seen some driver bugs before that would cause glIsTexture() to return true in this case:glDeleteTextures(1, &name);bool b = glIsTexture(name);If you bind a texture name that has previously been deleted, the glBindTexture() function actually recreates the texture object -- you don't have to call glGenTextures(). However, the newly created texture should have reverted to the initial state, which has a size of 0 x 0. If you're actually able to draw with it and see your texture image, then it's a driver bug.;Quote:Original post by Eric LengyelIf you bind a texture name that has previously been deleted, the glBindTexture() function actually recreates the texture object -- you don't have to call glGenTextures(). However, the newly created texture should have reverted to the initial state, which has a size of 0 x 0. If you're actually able to draw with it and see your texture image, then it's a driver bug.Ah, I did not know that glBindTexture actually creates a texture object if it needs to.  I'm guessiung that's why I'm able to rebind and draw with the deleted textures - the driver is merely marking them for deletion but not blanking the size data.  Although it's still a little odd that it should bind the same texture data - how does it know what to use if the name has been cleared?I guess it is just a driver issue and I have to take it on faith that the ram is cleared for use by new textures as needed.Thanks guys.   