[HOpenGL] Future of OpenGLRaw, OpenGL, GLUT, and GLUTRaw

Jason Dagit dagitj at gmail.com
Thu Sep 29 03:09:45 CEST 2011


Hello,

The last time I brought this discussion up with the list, I made some
mistakes.  Let's see if I can do things better this time :)

The GSoC student who was scheduled to work on improvements to the
bindings disappeared before writing any code.  I took a long holiday
for relaxation and also some time due to illness, but I'm back now.
So, I think now is a time when we can safely get a fresh start on
improving Haskell OpenGL/graphics support.  Also, one of the major
points of feedback was that the improved bindings need to have a nice
upgrade path, and for example not a jolting version bump.  I have not
forgotten that and I do want to incorporate it in the plans for
updates.  I'll try to be timely with my email responses going forward.

I'd like some feedback on the directions I outline below.  What
follows is my impression of the state of things.

I would like to see the most recent versions of the opengl bindings
make it into the Haskell platform.  Currently, the HP ships a version
of HOpenGL that is NOT the most recent.  Even if the bindings are not
included in the HP, I think the feedback they gave us is good and
should be implemented.

OpenGLRaw has the following open issues:
https://github.com/haskell-opengl/OpenGLRaw/issues

OpenGL has these issues:
https://github.com/haskell-opengl/OpenGL/issues

GLUT and GLUTRaw have no open issues, but there is one bug fix on
github that needs to be pushed to hackage.

The issues fit into a few categories:
  a) Support for specific versions of the OpenGL spec
  b) Refinement of the types (better modeling of C while easy to use in Haskell)
  c) Performance (MArray instances, if possible and fast floating
point conversions)
  d) OpenGL doesn't expose everything that OpenGLRaw already supports/exposes

Before Alexander disappeared he showed me that someone has started a
tool (available on github) for parsing the Khronos xml spec for
OpenGL.  We could use that code to auto generate much of the code in
OpenGLRaw.  I think that could be a fun and reasonable project for
someone.  How do others feel about using that to address (a) and (b)?
Of course, some work would need to be done first to prototype how it
should look/work and then the automated conversion could be developed.

I'm not personally all that worried about (d) because I like the *Raw
bindings better, but I think that the user base is split on that issue
with people holding both preferences.

I'd like to focus my attention on (a) and (b) first.  I also want to
make a bug fix release of all four packages that update the cabal
files and just do a minor version number bump.  Any objects to that?

Suggestions?

Thanks,
Jason



More information about the HOpenGL mailing list