[HOpenGL] Specialized versions of renderPrimitives?

Sven Panne sven.panne at aedion.de
Sat Oct 28 05:09:23 EDT 2006


Am Freitag, 27. Oktober 2006 13:25 schrieb Henning Thielemann:
> On Fri, 27 Oct 2006, Sven Panne wrote:
> > One thing I don't fully understand: What is not type safe in the current
> > API? The only thing I see is that one could use a different monad within
> > renderPrimitive to enforce that only correct OpenGL command could be
> > issued there.
>
> There are several OpenGL commands that make no sense in renderPrimitive
> like glViewport, glEnd, glFlush ... For modes like Lines, where pairs of
> vertices are needed, it could be enforced by types, that you can only pass
> pairs of vertices.

That's correct, but the problem is that the type system can only catch those 
simple kind of errors you've mentioned, which are rarely a problem in 
practice. What's much trickier to debug are semantic issues like the 
requirement that all polygons have to be convex, the order in which vertices 
are specified (for front/back determination), etc. In those cases, the type 
system is of no help at all. Furthermore, one has to consider that it's 
perfectly legal to specify things like the current color, the current normal 
etc. outside glBegin/glEnd. And finally, OpenGL simply discards any vertices 
which are "left over" for the primitive in question without signalling an 
error. This seems to be a very deliberate design decision, so I don't want to 
be stricter on the Haskell side.

> > But having direct access to the IO monad is more important to access
> > e.g. IORefs etc.
>
> I think it is enough to access them outside renderPrimitive.

For most cases it is, but people sometimes have strange ideas how to use an 
API. :-)

In a nutshell: I understand the desire to make things slighty more typesafe, 
but I don't think that exclusively providing the proposed functions would be 
a good tradeoff for "real" programs. The things you've mentioned can easily 
be implemented on top of the current binding. A question would be: Should 
utility functions like the ones you've mentioned be included in the Haskell 
binding, too? And if yes, what would be their exact types? What do other 
people on this list think?

Cheers,
   S.


More information about the HOpenGL mailing list