[HOpenGL] Shader API changes

[L Corbijn]

On Sun, Aug 4, 2013 at 4:47 PM, Sven Panne <svenpanne at gmail.com> wrote:
> 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/html/Graphics-Rendering-OpenGL-GL-Shaders.html)
> 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.
>
> _______________________________________________
> HOpenGL mailing list
> HOpenGL at haskell.org
> http://www.haskell.org/mailman/listinfo/hopengl

It sounds like a good idea to change the API. An attempt [1] was made
at extending it to include geometry shaders, but the result was in my
opinion not satisfactory.

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.

When doing so we indeed need to bump the major version. But as we are
revamping part of the API it might be worth wile to also redesign and
fix other parts as well. The following parts come to mind:
- The texture API, currently it is very old and can IIRC only be used
for 1,2,3D textures and maybe cubemaps. Furthermore without changing
the API this is probably not resolvable and otherwise not future
proof.
- Framebuffers and renderbuffers in combination with the default
framebuffer probably should be looked at. This is one of the more
complex parts and I am not sure about what I wrote (I had less
experience back then).
- Part of the sharderprogram API, the matrix uniforms needs urgent fixing.

Lars


[1]: https://github.com/haskell-opengl/OpenGL/pull/34