PDA

View Full Version : Does all that glGen* actually make sense?



Zengar
04-30-2007, 06:46 AM
It is just something I wonder about...

In OpenGL an object is identified by an integer constant. If you look at that, all glGen* calls seem to be totally useless, it is actually more convenient to me to allocate new "handles" myself.
Is there anything that speaks against it? Will a driver actually "allocate" a handle in a a special way that will benefit performance f I use the glGen* commands?

Overmind
04-30-2007, 08:10 AM
I can't tell you what the drivers actually do, but that's how I would implement it:

For associating the handles with an object, I have to use a hash table. I don't know anything about the integers I'm going to get, so I'd choose a very simple hash function, propably just a bitmask. Then I'd implement the glGen* functions so they generate zero collisions, to maximise performance.

But as I said, that's just how I would do it.

That being said, it's propably better programming style to use the glGen* functions instead of using arbitrary numbers as handles. And with Long Peaks, the integer handles will disappear, so if you plan to port your application to Long Peaks, using glGen* everywhere makes this task a lot easier ;)

Korval
04-30-2007, 10:23 AM
If you look at that, all glGen* calls seem to be totally useless, it is actually more convenient to me to allocate new "handles" myself. It's only convenient if you like to explicitly allocate the handles yourself, which requires remembering that, say, "texture handle #4 is the background image." That way, you won't "reallocate" the handle later.

I don't see the point in doing what the driver is perfectly willing to do.


Is there anything that speaks against it?You mean besides basic code-cleanliness? In regular (C/C++) code, you explicitly allocate an object, use it, and then explicitly delete it. I can understand wanting to remove the explicit deletion (garbage collection), but it's not like that handle actually does anything until you call glTexImage or glBufferData or whatever on it.

You're still going to have to construct the contents of the handle, so why not construct the handle itself?

This was an incredibly bone-headed decision from the original OpenGL 1.0.

k_szczech
04-30-2007, 07:23 PM
Zengar:
1. Imagine you're using some 3rd party library to display bitmap fonts. If it will use textures - you're doomed.
2. Imagine you made a cool effect and you want to make it available to use with various engines - now everybody else is doomed :)

Zengar
05-01-2007, 01:36 AM
Ok, that's a good point. Never thought about it that way, as I never used a third-party GL library, but this is really a good point... Still, a single function like glGenIDs() would suffice.

Won
05-01-2007, 02:16 PM
If you have some kind of object wrapper around your OpenGL objects (e.g. one that auto-destroys the underlying OpenGL object), you can just use the address of the object as the handle.

Of course, this is assuming no 3rd-party OpenGL module and your pointers are the same size as the object handles.