www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Open GL Bindings (was Re: GPGPU Arrays)

reply Mikola Lysenko <mclysenk mtu.edu> writes:
Personally, I think that it would be a bad idea to jump in and add
language-level support for GPU specific functions.  The technology is just
changing so fast right now that any effort would probably be hopelessly
obsolete within a few months.

That said, I think it would be good to get OpenGL / GLSL bindings into the
standard library.  When it comes to graphics, these are basically standard
interfaces, and official library support would be huge.  They provide all the
basic facilities for handling GPGPU, without the built in expiration date. 
Besides, we could leverage the excellent work that has already been done by
Aldacron et.al.  Off the top of my head, I can think of a several benefits of
this approach:

1. Reduced set up hassle

Right now building derelict is a huge PITA.  I know that Derek Parnell and
Aldacron have worked an incredible amount on simplifying this process, but it
is hardly automatic.  On Linux, I need to check out the latest version of
derelict, download build, compile some set up scripts, add paths to my project,
link in libraries, try compiling, then go back and add that -op switch I
forgot, etc. etc.

Making OpenGL work out of the box saves a huge amount of time and agony. 
Imagine how wonderful life could be if all one had to do to was add:

import opengl.gl;

Which leads into my next point:

2.  Built in OpenGL is more newbie friendly

When it comes to attracting novice programmers, graphics are extremely
important.  Most neophyte coders are interested in making games and getting
things running around on the screen.  From personal experience, I can say that
this is how I learned how to program, and also how many of my friends picked up
the skill.  The importance of graphics in attracting and educating new users
can not be overstated.

One of the reasons Python has been so effective in hooking programmers is that

likewise popular because of its XNA game development framework.  Java has been
used in web games since the 1990s, with decent success.   Even C compilers come
with OpenGL bindings installed by default.  For newbies, graphics are much more
compelling then a terminal.

Which brings me to my final point;

3. OpenGL is standard

And it has been the standard for graphics since the early 90s.  It works on Mac
OS, Linux and even Windows.  Solaris has OpenGL support.  Even video game
consoles have OpenGL bindings these days.  In fact, if you include the last
category, there are probably more hardware units out there that have OpenGL
support than there are systems that support ANSI C-style FILE stream IO.

Due to its popularity, this interface is probably not going to change much in
the coming years.  Granted Khronos group and company are revamping the
specification, but it is doubtful that this will happen at the expense of
backwards compatibility.

Besides, Aldacron has basically worked out most of the details involved in
getting future-proofed OpenGL bindings up and running.  I'm sure it shouldn't
be too hard to work out some scheme for incorporating a stable version of
derelict into the main trunk of either Phobos and/or Tango.  The added
development overhead would be so low in comparison to the huge benefit for the
community.

Of course not every little feature should get library level support, but it
just seems bizarre that something so essential is only available via a third
party add on.  Granted, we also need GUI utilities and template containers, but
I suspect that both of these will come in time.

-Mik
Jul 11 2007
next sibling parent Clay Smith <clayasaurus gmail.com> writes:
Mikola Lysenko wrote:

 Personally, I think that it would be a bad idea to jump in and add
language-level support for GPU specific functions.  The technology is just
changing so fast right now that any effort would probably be hopelessly
obsolete within a few months.
 
 That said, I think it would be good to get OpenGL / GLSL bindings into the
standard library.  When it comes to graphics, these are basically standard
interfaces, and official library support would be huge.  They provide all the
basic facilities for handling GPGPU, without the built in expiration date. 
Besides, we could leverage the excellent work that has already been done by
Aldacron et.al.  Off the top of my head, I can think of a several benefits of
this approach:
 
 1. Reduced set up hassle


It would be nice to have OGL standard lib support, but not necessary IMO.

For 1, just use DSSS.


 
 2.  Built in OpenGL is more newbie friendly
 


True... then again, OpenGL is kind of low level. A higher level lib 
would be even more newbie friendly, and will likely come with OGL 
bindings anyway.


 
 3. OpenGL is standard
 


I wouldn't mind seeing it, but it would put some stress on Walter and 
Mike to put through the major effort of keeping these bindings updated 
and working with the latest compiler and OpenGL versions.

~ Clay
Jul 11 2007
prev sibling next sibling parent Sebastian Beschke <s.beschke gmx.de> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Having OpenGL in the standard library is a neat idea; however, OpenGL
needs to interact with the window system. This means that you would need
to have some kind of window manager library inside the standard library,
too.
While that, too, would be neat, it would also bloat the standard library
and hinder the developer's freedom of choice. So I'm not sure if it's
worth it. Most people wanting to do some serious development with OpenGL
will need to set up a separate library (e.g. SDL/Derelict) along with it
anyway.

- -Sebastian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGlWsRKb/1n5A2TAMRArTOAJwKexUq5PIoxyUP1cdcuuQLclhmbwCeJuM1
8FhovItsh7psV0r7hGxBVVQ=
=Zwn2
-----END PGP SIGNATURE-----
Jul 11 2007
prev sibling next sibling parent reply Tristam MacDonald <swiftcoder gmail.com> writes:
Mikola Lysenko Wrote:


 That said, I think it would be good to get OpenGL / GLSL bindings into the
standard library.  When it comes to graphics, these are basically standard
interfaces, and official library support would be huge.  They provide all the
basic facilities for handling GPGPU, without the built in expiration date. 
Besides, we could leverage the excellent work that has already been done by
Aldacron et.al.  Off the top of my head, I can think of a several benefits of
this approach:
 
 1. Reduced set up hassle
 
 Right now building derelict is a huge PITA.  I know that Derek Parnell and
Aldacron have worked an incredible amount on simplifying this process, but it
is hardly automatic.  On Linux, I need to check out the latest version of
derelict, download build, compile some set up scripts, add paths to my project,
link in libraries, try compiling, then go back and add that -op switch I
forgot, etc. etc.
 
 Making OpenGL work out of the box saves a huge amount of time and agony. 
Imagine how wonderful life could be if all one had to do to was add:
 
 import opengl.gl;


So don't use derelict - I don't since I didn't want to port it to Mac.
Honestly, all you need is a GL header file (run h2d on gl.h and do 5 minutes
search & replace - or automate it in perl, whatever), and a platform context
toolkit, such as GLFW or SDL, of which several are already around. 

Even better, grab the XML definition files from GLee (www.elf-stone.com), and
build a generator script for D (I will do at some point, but haven't needed it
yet as I am on Mac, and we have GL 2 in core).


 Which leads into my next point:
 
 2.  Built in OpenGL is more newbie friendly
 
 When it comes to attracting novice programmers, graphics are extremely
important.  Most neophyte coders are interested in making games and getting
things running around on the screen.  From personal experience, I can say that
this is how I learned how to program, and also how many of my friends picked up
the skill.  The importance of graphics in attracting and educating new users
can not be overstated.
 
 One of the reasons Python has been so effective in hooking programmers is that

likewise popular because of its XNA game development framework.  Java has been
used in web games since the 1990s, with decent success.   Even C compilers come
with OpenGL bindings installed by default.  For newbies, graphics are much more
compelling then a terminal.


Tried setting up PyGame on a Mac recently? Or any system for that matter?
Newbie friendly I would not call it. I consider my 'installer foo' to be
stronger than most and it took several hours to get the pre-built binaries
working. I didn't even go near a source install.


 Which brings me to my final point;
 
 3. OpenGL is standard
 
 And it has been the standard for graphics since the early 90s.  It works on
Mac OS, Linux and even Windows.  Solaris has OpenGL support.  Even video game
consoles have OpenGL bindings these days.  In fact, if you include the last
category, there are probably more hardware units out there that have OpenGL
support than there are systems that support ANSI C-style FILE stream IO.
 
 Due to its popularity, this interface is probably not going to change much in
the coming years.  Granted Khronos group and company are revamping the
specification, but it is doubtful that this will happen at the expense of
backwards compatibility.
 
 Besides, Aldacron has basically worked out most of the details involved in
getting future-proofed OpenGL bindings up and running.  I'm sure it shouldn't
be too hard to work out some scheme for incorporating a stable version of
derelict into the main trunk of either Phobos and/or Tango.  The added
development overhead would be so low in comparison to the huge benefit for the
community.


Hang on, hang on! D isn't only a PC language is it? Don't forget all that
embedded hardware that will never see an OpenGL implementation. Direct
frame-buffer access would make more sense, but there are plenty of devices
without that as well.

And even if we only deal with PCs, OpenGL is not the only game in town (think
Direct3D), and OpenGL is not really that standard... each console manufacturer
rolls their own, with little regard for the core standard. Plus lets not forget
OpenGL ES, for all those mobile phones, etc.

And then of course there is the upcoming Khronos release, where OpenGL gets
split into 'classic' and 'modern', with the fixed function pipeline going the
way of the dinosaurs very quickly.

And as far as future proofing, a lot can be done, but how do you deal with an
API that has at times added extensions on a monthly basis?


 Of course not every little feature should get library level support, but it
just seems bizarre that something so essential is only available via a third
party add on.  Granted, we also need GUI utilities and template containers, but
I suspect that both of these will come in time.
 
 -Mik


I would say templated-containers are desperately needed, before everyone rolls
their own non-compatible versions. But GUI stuff (and I include OpenGL) in the
core library? That requires unified cross-platform GUI toolkits, and I don't
really think you will find anyone willing to invest a few million man-hours in
that can of worms. What is wrong with just using wxD or similar, rather than
polluting the standard lib?
Jul 11 2007
next sibling parent Mikola Lysenko <mclysenk mtu.edu> writes:
Tristam MacDonald Wrote:


 I would say templated-containers are desperately needed, before everyone rolls
their own non-compatible versions. But GUI stuff (and I include OpenGL) in the
core library? That requires unified cross-platform GUI toolkits, and I don't
really think you will find anyone willing to invest a few million man-hours in
that can of worms. What is wrong with just using wxD or similar, rather than
polluting the standard lib?
 


You have a good point.  I guess I was a bit frustrated after spending several
hours trying to port some derelict to code to my Mac, and I just felt like
ranting a bit.  Ultimately, it is not really fair to compare D and C in this
category, since for the onus for portability falls upon the OpenGL developers -
not the C standard.  Ultimately, putting OpenGL support directly in D is
probably a bit too short-sighted, when it comes right down to it.

That said, I think it would be nice if getting these things set up was a bit
easier and consistent.  Right now D OpenGL programs are hardly what one could
call portable.  I find that my old code is usually so damn brittle, that there
is little point in redistributing it or even saving it from one month to the
next.

-Mik
Jul 11 2007
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Tristam MacDonald wrote:


 So don't use derelict - I don't since I didn't want to port it to
 Mac. Honestly, all you need is a GL header file (run h2d on gl.h and
 do 5 minutes search & replace - or automate it in perl, whatever),
 and a platform context toolkit, such as GLFW or SDL, of which several
 are already around.


I put my bindings up at http://www.algonet.se/~afb/d/ a few years ago,
generated with... you guessed it: http://www.algonet.se/~afb/d/h2d.pl

...

 I would say templated-containers are desperately needed, before
 everyone rolls their own non-compatible versions. But GUI stuff (and
 I include OpenGL) in the core library? That requires unified
 cross-platform GUI toolkits, and I don't really think you will find
 anyone willing to invest a few million man-hours in that can of
 worms. What is wrong with just using wxD or similar, rather than
 polluting the standard lib?


Well put, but it wouldn't be too wrong to have e.g. old OpenGL 1.2
bindings or something simple for GUI like MinWin in the core either ?

--anders
Jul 12 2007
prev sibling next sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
Mikola Lysenko wrote:

 Personally, I think that it would be a bad idea to jump in and add
language-level support for GPU specific functions.  The technology is just
changing so fast right now that any effort would probably be hopelessly
obsolete within a few months.
 
 That said, I think it would be good to get OpenGL / GLSL bindings into the
standard library.  When it comes to graphics, these are basically standard
interfaces, and official library support would be huge.  They provide all the
basic facilities for handling GPGPU, without the built in expiration date. 
Besides, we could leverage the excellent work that has already been done by
Aldacron et.al.  Off the top of my head, I can think of a several benefits of
this approach:
 
 1. Reduced set up hassle
 
 Right now building derelict is a huge PITA.  I know that Derek Parnell and
Aldacron have worked an incredible amount on simplifying this process, but it
is hardly automatic.  On Linux, I need to check out the latest version of
derelict, download build, compile some set up scripts, add paths to my project,
link in libraries, try compiling, then go back and add that -op switch I
forgot, etc. etc.
 
 Making OpenGL work out of the box saves a huge amount of time and agony. 
Imagine how wonderful life could be if all one had to do to was add:
 
 import opengl.gl;
 
 Which leads into my next point:
 
 2.  Built in OpenGL is more newbie friendly
 
 When it comes to attracting novice programmers, graphics are extremely
important.  Most neophyte coders are interested in making games and getting
things running around on the screen.  From personal experience, I can say that
this is how I learned how to program, and also how many of my friends picked up
the skill.  The importance of graphics in attracting and educating new users
can not be overstated.
 
 One of the reasons Python has been so effective in hooking programmers is that

likewise popular because of its XNA game development framework.  Java has been
used in web games since the 1990s, with decent success.   Even C compilers come
with OpenGL bindings installed by default.  For newbies, graphics are much more
compelling then a terminal.
 
 Which brings me to my final point;
 
 3. OpenGL is standard
 
 And it has been the standard for graphics since the early 90s.  It works on
Mac OS, Linux and even Windows.  Solaris has OpenGL support.  Even video game
consoles have OpenGL bindings these days.  In fact, if you include the last
category, there are probably more hardware units out there that have OpenGL
support than there are systems that support ANSI C-style FILE stream IO.
 
 Due to its popularity, this interface is probably not going to change much in
the coming years.  Granted Khronos group and company are revamping the
specification, but it is doubtful that this will happen at the expense of
backwards compatibility.
 
 Besides, Aldacron has basically worked out most of the details involved in
getting future-proofed OpenGL bindings up and running.  I'm sure it shouldn't
be too hard to work out some scheme for incorporating a stable version of
derelict into the main trunk of either Phobos and/or Tango.  The added
development overhead would be so low in comparison to the huge benefit for the
community.
 
 Of course not every little feature should get library level support, but it
just seems bizarre that something so essential is only available via a third
party add on.  Granted, we also need GUI utilities and template containers, but
I suspect that both of these will come in time.
 
 -Mik


This is a very wise recommendation for D.  Building a platform library with
everything, including kitchen sink, can be a 
nightmare to maintain - adding something as rudimentary as GL is nowhere close
to that scenario, yet gives developers a 
much broader base to build upon.

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).

-- 
- EricAnderton at yahoo
Jul 12 2007
parent Mikola Lysenko <mikolalysenko gmail.com> writes:
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
Jul 12 2007
prev sibling next sibling parent reply "Craig Black" <cblack ara.com> writes:
I've heard that recent versions of OpenGL have some GPGPU support, but I 
don't know any details.  Anyone know where I could get this information?

-Craig
Jul 12 2007
parent reply Mikola Lysenko <mikolalysenko gmail.com> writes:
Craig Black Wrote:


 I've heard that recent versions of OpenGL have some GPGPU support, but I 
 don't know any details.  Anyone know where I could get this information?


GPGPU isn't really something that is supported, more as it is a terrible hack. 
In theory, all you need are a few basic OpenGL extensions to make it work.  The
basic idea is that you convert some (or all) of your computations into fragment
shader operations, then feed them your data in the form a texture to get your
result.  Making it all work isn't really pretty, and the tricks involved vary a
lot from problem to problem.  In general, the basic strategy is to get the GPU
to do as much as possible without CPU intervention.  For a brief tutorial see:

http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutorial.html

More recently, the GPGPU community has been moving toward unified languages
with much better support.  Right now the cutting edge technology is NVidia's
CUDA language.  It is essentially a hacked up version of GCC with some support
for running functions on the GPU.  I think it would be a very poor decision if
D were to try incorporating these features at this time, since current
development efforts are very closely tied to the hardware itself.  As NVidia
keeps iterating their GPU technology, I would expect that these languages will
change drastically - as well as their underlying interfaces.  Here is a link to
the CUDA toolkit/compiler:

http://developer.nvidia.com/object/cuda.html

-Mik
Jul 12 2007
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
With D's insane metaprogramming capabilities, someone probably just needs to
create a library for GPGPU similar to BLADE or something, where it analyzes
what you're trying to do with D code (passed in as a compile-time string) and
transforms it into GPU operations.

Mikola Lysenko Wrote:


 Craig Black Wrote:
 

 I've heard that recent versions of OpenGL have some GPGPU support, but I 
 don't know any details.  Anyone know where I could get this information?


 
 GPGPU isn't really something that is supported, more as it is a terrible hack.
 In theory, all you need are a few basic OpenGL extensions to make it work. 
The basic idea is that you convert some (or all) of your computations into
fragment shader operations, then feed them your data in the form a texture to
get your result.  Making it all work isn't really pretty, and the tricks
involved vary a lot from problem to problem.  In general, the basic strategy is
to get the GPU to do as much as possible without CPU intervention.  For a brief
tutorial see:
 
 http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutorial.html
 
 More recently, the GPGPU community has been moving toward unified languages
with much better support.  Right now the cutting edge technology is NVidia's
CUDA language.  It is essentially a hacked up version of GCC with some support
for running functions on the GPU.  I think it would be a very poor decision if
D were to try incorporating these features at this time, since current
development efforts are very closely tied to the hardware itself.  As NVidia
keeps iterating their GPU technology, I would expect that these languages will
change drastically - as well as their underlying interfaces.  Here is a link to
the CUDA toolkit/compiler:
 
 http://developer.nvidia.com/object/cuda.html
 
 -Mik
Jul 12 2007
parent Don Clugston <dac nospam.com.au> writes:
Robert Fraser wrote:

 With D's insane metaprogramming capabilities, someone probably just needs to
create a library for GPGPU similar to BLADE or something, where it analyzes
what you're trying to do with D code (passed in as a compile-time string) and
transforms it into GPU operations.


Indeed. I've had a quick look, and it actually looks straightforward. And a 
great opportunity to blow the socks off everything else. <g>

 
 Mikola Lysenko Wrote:
 

 Craig Black Wrote:


 I've heard that recent versions of OpenGL have some GPGPU support, but I 
 don't know any details.  Anyone know where I could get this information?


 GPGPU isn't really something that is supported, more as it is a terrible hack.
 In theory, all you need are a few basic OpenGL extensions to make it work. 
The basic idea is that you convert some (or all) of your computations into
fragment shader operations, then feed them your data in the form a texture to
get your result.  Making it all work isn't really pretty, and the tricks
involved vary a lot from problem to problem.  In general, the basic strategy is
to get the GPU to do as much as possible without CPU intervention.  For a brief
tutorial see:

 http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutorial.html

 More recently, the GPGPU community has been moving toward unified languages
with much better support.  Right now the cutting edge technology is NVidia's
CUDA language.  It is essentially a hacked up version of GCC with some support
for running functions on the GPU.  I think it would be a very poor decision if
D were to try incorporating these features at this time, since current
development efforts are very closely tied to the hardware itself.  As NVidia
keeps iterating their GPU technology, I would expect that these languages will
change drastically - as well as their underlying interfaces.  Here is a link to
the CUDA toolkit/compiler:

 http://developer.nvidia.com/object/cuda.html

 -Mik
Jul 12 2007
prev sibling parent reply Tristam MacDonald <swiftcoder gmail.com> writes:
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
Jul 13 2007
parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
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.
Jul 13 2007