Open GL Bindings (was Re: GPGPU Arrays)

[Mikola Lysenko]

Pragma Wrote:
> 
> If I may ask: what is your take on how GL should be provided as a D library?  There are any number of ways to go, 
> ranging from a full-fledged OO wrapper to a faithful port of the C headers and interfaces and everything in between 
> (assuming you're not proposing that we just fold Derelict in with Phobos or Tango).
> 

I think that the best strategy is to match the C interface as closely as possible.  The problem with using higher level D specific features is that OpenGL changes far too often for high level stuff to make much sense.  Limiting it to C functions basically ensures that no matter what the Khronos group & co. add, it can always be accessed directly.  This is especially true for vendor specific extensions which are often necessary for writing high performance GL code.

Likewise, many online examples are written for C-style OpenGL code.  Porting them to D is much easier if D matches the functionality exactly.  This ties in pretty well with the idea that adding OpenGL support should make D more newbie friendly.

Finally, OpenGL itself isn't tied down to any specific windowing library or platform.  If you stick to the C stuff, there is virtually no chance that you are going to step on the toes of any windowing kit out there.

However, this is also where the idea unravels a bit.  While OpenGL by itself is wholly reasonable to support, in order for it to actually do anything you need a host of other windowing and input functions.  One good compromise could be adding a GLUT-style windowing kit to D, but this would incur a substantial amount of work.  The problem is that all of the frameworks that I know of have at least one or two pathological flaws which make them break D in unpleasant ways.  In brief:

GLUT - Requires C-style function pointers for various window functions.  This typically breaks with D code, and requires a bunch of messy casting.  At the very minimal you would need to wrap ~90% of the library methods in a D language thunk.

SDL - Hijacks main() with SDL_main().  This causes a lot of current D code to break in unpleasant ways.  Also, it has a lot of bloat, such as various 2D sprite drawing things that are pretty much irrelevant for OpenGL applications.

GTK -  Far too huge.  Also requires a substantial runtime library install on windows.

Platform specific stuff (Win32, X, etc.) - In general decent usability from D, but completely unportable.

Overall, it seems like a bit of a dilemma.  Of all the systems I've seen probably the best candidate is GLFW.  It is small, supports static linking, has a consistent interface, and is widely portable.  The main drawback is that it is good for getting a window open and not much else.  It would probably function as a decent stand-in until someone gets a real UI library together for D.  Even then, it could still be a nice alternative for users who don't want to deal with a lot of extra set up hassle.

-Mik