View mode: basic / threaded / horizontal-split · Log in · Help
July 13, 2007
Re: Open GL Bindings (was Re: GPGPU Arrays)
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
July 13, 2007
Re: Open GL Bindings (was Re: GPGPU Arrays)
On Fri, 13 Jul 2007 07:27:05 -0400, Tristam MacDonald wrote:

> 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?
> 

I must say I agree here. There are way too many things to
consider for *any* type of graphics toolkit for it to go in the
standard library IMHO.

What we really need is people to start using DSSS. And if necessary
make DSSS easier to use. That would make it really easy for anyone
to get the libraries they want.
Top | Discussion index | About this forum | D home