I thought glCopyTexImage2D()
was slower than glCopyTexSubImage2D()
but I tried and it seams to be exactly the same.
So my question is : Is it usefull to
use glCopyTexSubImage2D ?

That’s all!

Well, I think it is senseful. I think so, because CopyTexImage CREATES a texture each time and WILL NOT delete the old texture, so you have to delete the old texture yourself and all in all the update of your texture will look like:

glDeleteTextures (delete old)
glGenTextures (create new id)
glBindTexture (selecting id)
glTexCopySubImage2D (loading image from fb)
glTexParameterf… (filter mag) (all settings)
glTexParameterf… (filter min)
glTexParameterf… (wrap s)
glTexParameterf… (wrap t)

instead of only
glBindTexture (selecting)
glTexCopySubImage2D (loading image)

So first of all you have only a 5th of the API calls. I don’t know, how your test program looks like and if you anyway deleted and recreated the texture in it as it’s needed. If not… well, then you know now, what caused why suddenly 40 MB of your free memory stood missing after quitting your program . On the other hand you also totally fragment your memory through this. If you want to try write a little program always reserving and freeing little blocks of memory. Windows will do this may be one hour if you are lucky and then freeze away or show you the good old blue screen. So well… except you want to poke the driver… always use the one of the functions which is senseful. In case of updating textures: glCopyTexSubImage2D .


I really thank you.

You were right : “40 MB of my free memory stood missing after quitting my program”

Well, I did the same mistake once too, hehe. I also thought that OpenGL would automatically free the old texture if I store a new one using the same ID. And every time after loading a savegame I had suddenly 30 MB memory less . I debugged and debugged and found nothing… till I asked myself if it may be cause of the textures .