[Haskell-cafe] New OpenGL package: efficient way to convert datatypes?

[Peter Verswyvelen]

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 <bugfact at gmail.com> wrote:
> 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 <vandijk.roel at gmail.com>
> 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.
>
>