Is it ok to use a random texture ID?

Hi guys,

Instead of using glGenTextures() to get an unused texture ID. Can I randomly choose a number, say, 99999 and use it?

I will, of course, query:

glIsTexture( m_texture )

and make sure it’s false before proceeding.

Here’s some background:

I am developing an image slideshow app for the mac. Previewing the slideshow is flawless. To save the slideshow, I am rendering to an FBO. I create an AGL context, instantiate a texture with glGenTextures() and render to a frame buffer. All’s well except for a minor issue.

After I’ve saved the slideshow and return to the main window, all my image thumbnails are grey, i.e. the textures have been cleared.

I have investigated it and found out that the image thumbnails and my FBO texture somehow have the same texture ID. When I delete my FBO texture at the end of the slideshow saving operation, the thumbnail textures are also lost. This is weird because I have an AGL context during saving, and the main UI has another AGL context, presumably created in the background by Core Image and which I have no control on.

So my options, as I see it now, is to:

  1. Not delete the FBO texture.
  2. Randomly choose a high texture ID in the hopes that the main UI will not be using it.

Actually I read that you do not necessarily need to delete your texture if you are deleting the AGL opengl context. Because deleting your openGL context automatically deletes all associated textures. Is this true? If yes, option 1 makes more sense.

I do realize that there are funny things happening here that I can’t really explain. For example, after I’ve saved my image slideshow to an .mov file, I delete the context, which was created in the same class. By right, it should not affect textures created in another context. But it does, and I seriously can’t explain that.

Anyways thanks for reading this and do it me know if you have any suggestions.

Hi,
I think rather than generating a new texture id yourself, it is generally preferrable to use GenTextures. You should instead identify why the textures are deleted in the first place. Why don’t you use the GLcontext of the main application for fbo and thumbnail textures. That way you only need to create textures onces and then when done they could be deleted.

the image thumbnails and my FBO texture somehow have the same texture ID.

You should recheck your code or if possible share the relevant code snippets with us of how you are setting up the fbo and thumbnails texture. If the texture ids are same, the output will be dependent on who writes to the texture last (fbo or thumbnail). This also explains why on deletion, both fbo and thumbnail textures are grey since they are using the same texture id.

With old GL, 1.0 to 2.1, yes you can use any ID you want.

Actually I read that you do not necessarily need to delete your texture if you are deleting the AGL opengl context. Because deleting your openGL context automatically deletes all associated textures. Is this true? If yes, option 1 makes more sense.

I think that is a standard assumption on all OSes. The same can be said for new and delete from C++ or whatever, once the program closes the OS should release all the memory.

Tnx guys. I’ve chosen the simplest solution. I will not delete the texture and let it go out of context when I delete the AGL context. That somehow solves my problem.

Make sure you enable texture object sharing, the API varies platform to platform. On Apple the second argument to aglCreateContext for the additional context should list the original context as the share argument.

You should not have a problem then. If you still do it may be a bug, in which case you could try working around it by creating a load of handles in the original context, they are guaranteed to be unique integers. You could also create a large group of handles including your FBO texture in a single call. You don’t have to delete the handles in the block you created them as and you don’t have to delete them at all really.

I suspect you’ve simply missed the original context as an argument to the new context creation.