
Hi list, I have two questions: 1. What is holding the release of OpenGLRawGen (see [1]) back? I tried it and it works quite well, although there seems to be a problem with at least some functions: glGenVertexArrays and the related functions are not exported by any core module, although it's part of the core since OpenGL 3.0. I tried to find the source of this error in the code, but the codebase is quite big and I still don't know where things go wrong. 2. Looking at the source of HSOpenGLRaw.c it seems to be quite costly to call OpenGL functions, because every time the function pointer has to be retrieved. Or does GetProcAdress (or the equivalent on Mac and Linux) cache previous results? Other librarys (like GLEW or gl3w for C) load the functions pointers once at initialization (which has of course to be done explicitly unlike in HOpenGL), which I guess is for efficiency reasons. [1] http://www.haskell.org/pipermail/hopengl/2012-January/001073.html

On Fri, Aug 24, 2012 at 2:07 PM, Fabian Binz
Hi list,
I have two questions:
1. What is holding the release of OpenGLRawGen (see [1]) back? I tried it and it works quite well, although there seems to be a problem with at least some functions: glGenVertexArrays and the related functions are not exported by any core module, although it’s part of the core since OpenGL 3.0. I tried to find the source of this error in the code, but the codebase is quite big and I still don’t know where things go wrong.
What release do you mean, one on hackage or the use of it to generate an new OpenGLRaw? A release on hackage might not be very useful as it's a rather specific development tool. I don't know why it's not used, maybe failure to promote it from my site, not being on hackage, lack of time or interest could all be reasons. The error with glGenVertexArrays (and a lot more functions) was caused by a bug in the reuse options (the gl.spec has some comments on that the functions are reused from an extension, which cannot be parsed decently). I've fixed the bug in commit [5a38bc] on github.
2. Looking at the source of HSOpenGLRaw.c it seems to be quite costly to call OpenGL functions, because every time the function pointer has to be retrieved. Or does GetProcAdress (or the equivalent on Mac and Linux) cache previous results? Other librarys (like GLEW or gl3w for C) load the functions pointers once at initialization (which has of course to be done explicitly unlike in HOpenGL), which I guess is for efficiency reasons.
It is effectively cached. The current implementation of functions is done via the EXTENSION_ENTRY macro defined in HsOpenGLRaw.h. OpenGLRawGen makes the same code as the macro execution would (that's the theory). For every function the macro makes three declarations. - a dynamic foreign import :: FunPtr t -> t - the actual function pointer :: FunPtr t - the actual function :: t Where t is the type of the actual OpenGL function. The actual function pointer is retrieved via an 'unsafePerformIO'-like trick namely thePointerName = unsafePerformIO $ getExtensionEntry 'functionName'. Which is marked as NOINLINE, and is only evaluated once (on first use) and the result is reused thereafter (as FunPtr t is pure). getExtensionEntry is making (indirectly) the calls to hs_OpenGLRaw_getProcAdress. Lars [5a38bc] https://github.com/Laar/OpenGLRawgen/commit/5a38bc297e0a3aafd153b860f4ccabd1...
[1] http://www.haskell.org/pipermail/hopengl/2012-January/001073.html
_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl
participants (2)
-
Fabian Binz
-
L Corbijn