
I just converted an old HOpenGL application of mine to the new Haskell
OpenGL using GHC 6.12.1, using realToFrac to convert Double to
GLdouble.
The performance dropped from over 800 frames per second to 10 frames
per second... Using unsafeCoerce I got 800 FPS again.
So for all of you using new OpenGL package, be warned about this, it
can really kill performance (it's a known issue to those how already
knew it ;-)
I can't use the logfloat package's realToFrac function since it complains:
ElasticCollision.hs:317:28:
No instance for (Data.Number.Transfinite.Transfinite GL.GLdouble)
arising from a use of `realToFrac' at ElasticCollision.hs:317:28-39
Possible fix:
add an instance declaration for
(Data.Number.Transfinite.Transfinite GL.GLdouble)
In the first argument of `Vertex2', namely `(realToFrac x)'
In the expression: Vertex2 (realToFrac x) (realToFrac y)
In the definition of `glVertex2':
glVertex2 x y = Vertex2 (realToFrac x) (realToFrac y)
On Wed, Sep 30, 2009 at 4:06 PM, Peter Verswyvelen
I don't want to use the GL types directly since the OpenGL renderer is not exposes in the rest of the API. I was hoping that realToFrac would be a nop in case it would be identical to an unsafeCoerce. I guess one could make rules for that, but this tickets makes me wander if that really works: http://hackage.haskell.org/trac/ghc/ticket/1434
On Wed, Sep 30, 2009 at 4:58 PM, Roel van Dijk
wrote: If you are *really* sure that the runtime representation is the same you could use usafeCoerce. You could use a small test function for profiling, something like:
convertGLfloat :: GLfloat -> Float convertGLFloat = realToFrac -- convertGLFloat = unsafeCoerce
and toggle between the two (assuming you won't get a segmentation fault).
Another option is to not convert at all but use the GL types everywhere. Either explicitly or by exploiting polymorphism.