[HOpenGL] [Haskell-cafe] ANN: Haskell OpenGL package updates

Jason Dagit dagitj at gmail.com
Sat Oct 29 01:09:31 CEST 2011


On Fri, Oct 28, 2011 at 2:07 PM, Edward Kmett <ekmett at gmail.com> wrote:
> Jason,
> Thank you for taking ownership of HOpenGL!

Thanks!

> I would like to make a formal request for there to be some way to get access
> to either
> Graphics.Rendering.OpenGL.Raw.Core31.TypesInternal
> or that
> Graphics.Rendering.OpenGL.Raw.Core31.Types
> re-export the newtype wrappers it places around CDouble and CFloat.
> As things stand the only way to work with them is to pointlessly round-trip
> through rational or pray that GHC is smart enough to automatically convert
> once it sees through the newtype, which it isn't, potentially costing me
> orders of magnitude of performance in tight loops in exchange for
> implementation freedom the current OpenGL bindings do not use on any
> platform.

Yes, it's a real problem.  I think there are a couple directions we
could move in (and some may not even be mutually exclusive).

Andy Gill created this workaround:
{-# RULES "realToFrac/a->GLfloat" realToFrac = \x -> GLfloat (realToFrac x)
#-}
{-# RULES "realToFrac/GLfloat->a" realToFrac = \(GLfloat x) -> realToFrac x
#-}

That one helps a lot for most people.

Someone made a libraries proposal that also helps the conversion
situation but I don't have the details handy at the moment.

If you read here, I'd like to get some MArray support in and I think
it's possible, although I haven't the idea I proposed yet:
http://www.haskell.org/pipermail/haskell-cafe/2011-March/090511.html

Another thing we could do is find a different balance between newtypes
and the C types.

I'm totally onboard with exposing all of OpenGLRaw.  I think we just
need to sufficiently document the "internal" bits so that only people
who absolutely need them will use them.  That's how I see ByteString
and it seems to be working there.

Thanks for your suggestion (and your pull request on github, yay for
collaborative tools!).

Jason



More information about the HOpenGL mailing list