August 2013 - HOpenGL

Haddock documentation on Travis CI
by Sven Panne 25 Aug '13

25 Aug '13

I'd like to build/test the Haddock documentation for the OpenGL packages on Travis CI a bit more, so I've tweaked the configuration a bit by building the Haddock documentation for the dependencies first. One problem remains: There seems to be no installed Haddock documentation for the Haskell platform itself on Travis CI, so we get tons of warnings, e.g. here: https://travis-ci.org/haskell-opengl/GLUT Does anybody have a clue how to fix this (probably via some apt-get magic in the before-install section)? Cheers, S.

2 2

Shader API changes
by Sven Panne 16 Aug '13

16 Aug '13

While going through the latest and greatest Red Book (8th ed., for OpenGL 4.3), I've come to the conclusion that the current shader API (http://lambda.haskell.org/platform/doc/current/packages/OpenGL-2.8.0.0/doc/…) is fundamentally broken. It was designed at a time when shaders were very new, so I had very little experience with them and how to expose them to Haskell nicely, and the underlying C API has been vastly extended over the last few years. As I see it, there is no good backwards-compatible way of improving the API, even though I would prefer that: I would really like to change Shader from a type class into a normal algebraic data type, changing quite a few signatures because of that on the way. This would make things much easier and straightforward, and it would be much more in the spirit of the OpenGL C API, where all shader types are treated more or less the same. Corollary: http://www.haskell.org/haskellwiki/Package_versioning_policy implies that the major version of the OpenGL package has to change, and because re-exports the GLUT package version number has to change, too, correct? Any thoughts, opinions and proposals are appreciated. Cheers, S.

3 3

Fwd: Shader API changes
by Sven Panne 12 Aug '13

12 Aug '13

[ Wrong kind of reply... :-P ] ---------- Forwarded message ---------- From: Sven Panne <svenpanne(a)gmail.com> Date: 2013/8/12 Subject: Re: [HOpenGL] Shader API changes To: L Corbijn <aspergesoepje(a)gmail.com> 2013/8/11 L Corbijn <aspergesoepje(a)gmail.com>: > As there is no function that depends on the shadertype that I could > find on the reference card for OpenGL 4.3 (though I could have missed > it). So switching to an algebraic data type seems to me as a good > idea. The only disadvantage is that it can no longer be a ObjectName, > as the shader needs a type to create. [...] All shaders share the same name space, so there is no problem regarding OpenGL semantics. The last point regarding ObjectName is the real problem, and it needs some thought to resolve it nicely. As a first brainstorming step let's look at all OpenGL objects and their related lifetime API (see section 2.5, "Objects and the Object Model"): ---------------------------------------------------------------------- * Buffer Objects void GenBuffers( sizei n, uint *buffers ); void DeleteBuffers( sizei n, const uint *buffers ); boolean IsBuffer( uint buffer ); * Shader Objects uint CreateShader( enum type ); void DeleteShader( uint shader ); boolean IsShader( uint shader ); * Program Objects uint CreateProgram( void ); void DeleteProgram( uint program ); boolean IsProgram( uint program ); * Program Pipeline Objects void GenProgramPipelines( sizei n, uint *pipelines ); void DeleteProgramPipelines( sizei n, const uint *pipelines ); boolean IsProgramPipeline( uint pipeline ); * Texture Objects void GenTextures( sizei n, uint *textures ); void DeleteTextures( sizei n, const uint *textures ); boolean IsTexture( uint texture ); * Sampler Objects void GenSamplers( sizei count, uint *samplers ); void DeleteSamplers( sizei count, const uint *samplers ); boolean IsSampler( uint sampler ); * Renderbuffer Objects void GenRenderbuffers( sizei n, uint *renderbuffers ); void DeleteRenderbuffers( sizei n, const uint *renderbuffers ); boolean IsRenderbuffer( uint renderbuffer ); * Framebuffer Objects void GenFramebuffers( sizei n, uint *framebuffers ); void DeleteFramebuffers( sizei n, const uint *framebuffers ); boolean IsFramebuffer( uint framebuffer ); * Vertex Array Objects void GenVertexArrays( sizei n, uint *arrays ); void DeleteVertexArrays( sizei n, const uint *arrays ); boolean IsVertexArray( uint array ); * Transform Feedback Objects void GenTransformFeedbacks( sizei n, uint *ids ); void DeleteTransformFeedbacks( sizei n, const uint *ids ); boolean IsTransformFeedback( uint id ); * Query Objects void GenQueries( sizei n, uint *ids ); void DeleteQueries( sizei n, const uint *ids ); boolean IsQuery( uint id ); * Sync Objects sync FenceSync( enum condition, bitfield flags ); void DeleteSync( sync sync ); boolean IsSync( sync sync ); * Display Lists uint GenLists( sizei s ); void DeleteLists( uint list, sizei range ); boolean IsList( uint list ); ---------------------------------------------------------------------- Looking at this, the following kind of objects are a perfect fit for the current ObjectName class: * Buffer Objects * Program Pipeline Objects * Texture Objects * Sampler Objects * Renderbuffer Objects * Framebuffer Objects * Vertex Array Objects * Transform Feedback Objects * Query Objects The following two object kinds fit, although not 100% perfectly, but this can easily be handled e.g. via comments and exporting a constructor: * Program Objects: CreateProgram directly creates a name *and* the object. * Display Lists: List names don't have to be generated via GenLists, and GenLists itself is guaranteed to return a consecutive range of names. The following two object kinds are the tricky ones: * Shader Objects: Just like program objects, their name and the associated object are created simultaneously. Furthermore, creation needs a parameter (the shader type). * Sync Objects: The same problems as for shader objects (direct creation + arguments for creation), in addition the object identifier is an opaque pointer (GLsync) instead of a GLuint, but the latter fact can be hidden. Any suggestions regarding how to reflect this on the Haskell side? It would be nice to keep ObjectName, perhaps with some modifications and/or additions like e.g. another type class. There are probably several ways of doing this, I would really like to get some ideas and feedback before I rush into changing things.

1 1

Back again
by Sven Panne 12 Aug '13

12 Aug '13

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. 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? 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. * 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. * 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. * 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. * Finally Khronos has released the OpenGL registry in a less braindead format (http://www.opengl.org/discussion_boards/showthread.php/181927-New-XML-based…) 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. * 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. Cheers, S.

6 8