suggestion: Unify Foo and FooEXT functions into Foo

[hajimehoshi]

For example, v2.1 package includes GenFramebuffers and GenFramebuffersEXT. I used GenFramebuffers and it worked well on my machine but not on some machines. If I understand correctly, GenFramebuffers works if the machine has OpenGL 3.x or later, and GenFramebufferEXT works even in machines that don't have OpenGL 3.x (but have the extension). EXT versions work in wider range of machines than non-EXT version. I'm not sure, this might be wrong.

Then, I'm now confused when to use GenFramebuffers and when to use GenFramebuffersEXT. I can use GenFramebufersEXT as a fallback of GenFrambuffers (or vise versa?), but should callers care of this? Can we have unified function, GenFramebuffers in this case, and always use them?

[dmitshur]

I can use GenFramebufersEXT as a fallback of GenFrambuffers (or vise versa?), but should callers care of this? Can we have unified function, GenFramebuffers in this case, and always use them?

Adding fallback code may have negative performance implications. That's something that should be considered when making a decision here.

I'm not completely sure what to do here. I suspect we want to keep these bindings as low-level and close to metal as possible, and so them mapping directly 1:1 to the equivalent C calls makes sense.

If it's possible to precompute the functions during context initialization so there's no runtime overhead for each function call, then this is more viable.

These are just some high level thoughts off the top of my head. This seems like a hard decision to make, and it would need some more time to investigate in depth.

[jeff-emanuel]

You must be careful about doing this in general because the EXT function is not always equivalent to the function without EXT. For example, from https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_framebuffer_object.txt:

Note that the functions BindFramebuffer and BindFramebufferEXT are not aliases and neither are the functions BindRenderbuffer and BindRenderbufferEXT. Because object creation occurs when the framebuffer object is bound for the first time, a framebuffer object can be shared across contexts only if it was first bound with BindFramebufferEXT. Framebuffers first bound with BindFramebuffer may not be shared across contexts. Framebuffer objects created with BindFramebufferEXT may subsequently be bound using BindFramebuffer. Framebuffer objects created with BindFramebuffer may be bound with BindFramebufferEXT provided they are bound to the same context they were created on.

I prefer keeping the extension functions explicit.

[hajimehoshi]

Thank you for replying. So my current questions are:

• Is there any cases that BindFramebuffer is preferable to BindFramebufferEXT? I feel like BindFramebufferEXT is always available when BIndFramebuffer is available.
• Is there a way to detect if a function is available or not? In C, I could check this by checking the function pointer is null or not.

[pwaller]

@hajimehoshi it sounds like this one fizzled out? I suggest to close it - please reopen if you wish to continue pursuing this! :)

My inclination is that it's better to keep the functions explicit, too, but I'd need to see some examples to make a more informed decision.