[HOpenGL] Back again

[Jason Dagit]

On Mon, Jul 22, 2013 at 2:23 AM, Sven Panne <svenpanne at gmail.com> wrote:
> After a few HOpenGL-free years caused by personal and job-related
> circumstances, I'd like to work on this again. First of thanks to all
> the people involved in keeping the binding alive, especially Jason!
> Having the packages in the Haskell platform is simply great, because
> it improves the visibility of the binding a lot and will keep new
> users (and new bug reports ;-) coming.

Welcome back!

> I've browsed through the mailing list archives, so here are a few
> miscellaneous remarks:
>
>  *  The StateVar/Tensor/ObjectName packages are now in the OpenGL
> package itself (in a different namespace), and the previous standalone
> packages are still available, too. Although I don't think it is a
> perfect solution, it was probably done to get the OpenGL packages into
> the Haskell platform, right?

Yes, that is exactly why. I prefer to have the packages split up.

> If this was the motivation, I think the
> price to pay was well worth it. The OpenAL/ALUT packages use the
> assimilated packages, too, so I should probably update the former ones
> to use the latter ones. This will introduce a dependency of
> OpenAL/ALUT on OpenGL, something I wanted to avoid. But I think there
> are very few programs using OpenAL without OpenGL, and the latter is
> now universally available via the Haskell platformm, so this should be
> the right way to proceed.

That's probably right. It looks like OpenAL is now proprietary. (See
license information: http://en.wikipedia.org/wiki/OpenAL). So I don't
really know if it makes sense to bother with OpenAL bindings. I know
several folks have stopped considering it completely.

>  * What was the exact motivation for using type synonyms instead of
> the former renamings (newtypes) for the OpenGL types? Were there any
> *real* problems or only potential/hypothetical ones? I am a bit torn
> between those alternatives, so I'd like to learn the experience of
> other people, including their opinions.

It's a mix. Andy Gill sent patches at one point that introduce a {-#
RULE #-} that removed the conversion, it looked like this:
{-# RULES "realToFrac/a->GLfloat" realToFrac = \x -> GLfloat (realToFrac x) #-}
{-# RULES "realToFrac/GLfloat->a" realToFrac = \(GLfloat x) -> realToFrac x #-}

He did that because it had very real performance implications. The
default implementation of realToFrac goes through Rational :(

With the type synonyms it's trivial to use the GL types with unboxed
Data.Vectors. With the newtype wrappers you have to dig pretty deep
into GHC to get the unboxing magic. To me that sounded like a
maintenance headache.

The other benefit is that the C types have more instances in the
standard library than the GL types. So that makes it just that much
easier to use them with other libraries (for example, vector-space).
Admittedly this issue is minor. As we could provide a separate package
with common instances or make sure to include all the RULES necessary
to make it efficient to convert.

>  * The examples have bit-rotted, e.g. SmoothOpenGL3.hs yields an
> InvalidOperation in triangle's vertexAttribPointer calls, 'catch'
> should probably be replaced by Control.Exception.{catch,IOException},
> etc. Apart from fixing them, having GLUT versions of nehe-tuts in the
> GLUT package would be great. I really like the idea of GLUT being a
> one-stop-shop for tons of examples regarding the usage of the
> OpenGL/OpenGLRaw packages.

Ah, that would be my fault. I haven't been updating the examples. I
don't like GLUT for various reasons. For example, the translation of
the nehe-tuts that I maintain use OpenGLRaw and GLFW-b instead of
OpenGL and GLUT.

>  * Currently the binding doesn't work out-of-the box with ghci on
> Ubuntu 12.04 if you have NVIDIA drivers installed in addition to the
> Mesa ones. I have an ugly fix (adding /usr/lib/nvidia/current to
> OpenGLRaw's library-dirs), but I'd like to solve this more cleanly.
> More about this in a separate mail.

We should fix that.

>  * Finally Khronos has released the OpenGL registry in a less
> braindead format
> (http://www.opengl.org/discussion_boards/showthread.php/181927-New-XML-based-API-Registry-released?p=1251759),
> so there is a good chance now that the OpenGLRaw package can be
> completely autogenerated, something I wanted to do for ages. Judging
> from the HOpenGL mailing list, Lars is already looking into it, so
> let's coordinate our efforts here, preferably in a separate mail
> thread. My main concerns here are: Include the generator (plus
> pre-generated bindings) in the OpenGLRaw package, it really belongs
> there. Don't put anything clever into OpenGLRaw, it should really,
> really be a plain, straightforward 1:1 mapping of the registry. No
> name mangling, structural modifications etc. apart from things
> automatically derivable from the XML registry. A big question remains:
> Can we generate the (un-)marshaling functions already in OpenGLRaw?
> The XML registry has <groups>/<group> tags, but I fear that they are
> still too incomplete/incorrect to be of any use for the Haskell
> binding. On the positive side, I think that it should be possible to
> upstream changes to the registry to make it more useful in general. I
> had contact with Jon Leech in the past, and he has always been very
> open and helpful.

Sounds good.

>  * Given the fact that OpenGL 4.3 is quite different from OpenGL in
> the "old days", there are quite a few design decisions in the OpenGL
> (convenience) package that I would do differently nowadays. But I
> think with the feedback from the community we can gradually tweak this
> layer to something more useful and up-to-date. Perhaps we can somehow
> re-arrange things to be more in line with OpenGL versions/profiles,
> but whatever we do, we should not drop support for "old skool" OpenGL,
> there are *tons* of tutorials, books and courses relying on it, and
> even NVIDIA has effectively promised to support this forever.

That's fine with me.

Send me your Github username and I can give you a commit bit in the
haskell-opengl organization.

Thanks!
Jason