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

L Corbijn aspergesoepje at gmail.com
Sat Oct 1 19:41:31 CEST 2011


Oops forgot to send it also to the list.
Lars

....

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

Most of the issues regarding regarding GL3.0 have been implemented
though not yet merged, partially because I'm not yet confident that
everything is there and for some parts I'm not yet happy about what
I've written.

...

> 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 believe that something has been done by Sven in the past (see the
files in the OpenGL repo under specs).
I've been working on some things (from scratch) for about a month
(though not very active, due to lack of time).

There are some difficult points about generating the binding from the
spec files.  Their are some inconsistencies in the enum spec file
(which Khronos hasn't fixed, and probably isn't gone fix soon), but
they can be fixed by hand. A different problem is that information
needed for creating a type safe haskell binding is missing. For
example enumerations aren't grouped and 'ObjectName'-s aren't
identified.

As OpenGLRaw doesn't need that information it can be created from the
files. I've created code that does that, though it's missing some
essential things.
For generating OpenGL marshalling there is some need for extra
information before it can be generated. I'm currently experimenting
with an xml format I've made. Though the code generator is still
absent, I'm trying to make one that is sturdy enough to be able to
handle the things OpenGL throws at it.

One major question about any code generation is how it should affect
the current implementation, should it replace, augment the current
library or should it be only a tool for the developers speeding up the
code process. My personal preference goes to augment and replace (in
the future).
A generator that can fully replace/rewrite the code could have some
extra (partial) back-ends that could for example generate memory
managed code or code that reduces needles GLfunction calls.

> ...
>
> 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?
>
> ...
Sounds good.



More information about the HOpenGL mailing list