[aldacron]

When loading OpenGL extensions, I first check the extension string for each case using std.string.find. This worked well when I was only loading the GL_ARB extensions. Once I added GL_EXT, the increase in load time was noticeable. Right now, all of the GL_NV extensions are prototyped but before I implement the loading code I need to make a decision. The load time just is not acceptable.

Currently, all extensions are loaded with a call to dglLoadExtensions. This also loads all core version-specific open gl functions above 1.1. I'm going to change this. First, I'll implement a dglLoadCore. This will load the version-specific functions above 1.1 (1.1 will still be loaded in dglLoad, since the shared lib must be loaded and a context created first anyway). Each extension line will have its own load function: dglLoadARB, dglLoadEXT, dglLoadNV, and so on. This will eliminate the need to load all extensions all the time. If the user still desires to load all extensions, the current functionality will be retained in dglLoadExtensions.

Now, to improve the case where all extensions are loaded I need to either replace the calls to finc with something else (perhaps using c-style strings with strcmp?) OR just say bugger with checking the extension string and just attempt to load each extension. If the extension is not present, the getProc call will return null and life goes on. Either case will require a signficant rewrite (ugh ). A third option would be to leave it as is. I'm not too keen on doing that though. For some apps a slow startup would be noticeable.

I'd really like some opinions on this. Although this project is primarily for me, I have put it out here for the world to make use of. So whatever potential users might think will have a huge impact on how I handle this.

Thanks

[andy]

You could make proxy functions that search for the extension and replace themselves on call.

[aldacron]

Proxies are great for known states, such as during lazy instatiation when you are instancing a class which you know exists, or when you know the function you are calling exists in the shared lib you are loading (such as with the core GL functions). In those cases, a failure to instantiate the object or load the function really would be an exceptional case.

I just see it as a different story with OpenGL extensions. The absence of one extension or another is not exceptional. Also, one extension may have several functions associated with it. By loading all of the available extensions up front, Derelict can ensure that if one of the functions is not loaded for some reason, then that extension will be marked as not available (which the code in its current state does not account for, ahem). So when the user queries for a specific extension, they can be sure that all of the functions for that extension were successfully loaded. A proxy would take that burden out of the library and put it in the user's hands.

[aldacron]

[andy]

You have a point.

What you could do, though, is have the proxy function assert that an extention has been checked before its first use. This would prevent people from making apps that instantly explode when used on different hardware.

(they would instantly explode on *all* hardware)
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear