Open GL Bindings (was Re: GPGPU Arrays)

[Tristam MacDonald]

Why, why, why would you want a GUI toolkit in the core library? What is wrong with having a separate (possibly installed by default) GUI lib?

Phobos is already over a megabyte in most environments, and only shipped as a static library. If I am distributing a simple command line tool, I *do not* want another meg (and it could easily be 3 times that) of GUI junk statically linked in. I know that dead code stripping and similar *should* remove that excess junk, but from my experience this is not reliable.

Even if phobos/tango, etc. are shipped as dynamic libraries, they still don't come pre-installed in most environments, necessitating that any installers include them, so size is still a concern.

And beyond all that, OpenGL is not really a generally useful tool. With out a full fledged GUI toolkit (with all widgets, etc.) that allows embedding OpenGL contexts in controls, it is only really useful for games and screensavers. Libraries such as GLFW suffer from a severe sparsity of features, as they are only designed to support games.

Seriously, how hard is it to drop gl.d and glfw.d into your project?

Mikola Lysenko Wrote:

> 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