[Haskell] GLUT gears speed

Sven Panne Sven.Panne at aedion.de
Sat Feb 18 14:16:16 EST 2006

Am Montag, 16. Januar 2006 21:52 schrieb Wolfgang Jeltsch:
> Am Montag, 16. Januar 2006 15:16 schrieb Sebastian Sylvan:
> > or (better) vertex buffer objects.
> What's this?

The basic idea behind buffer objects is a general mechanism which allows the 
driver to keep huge amounts of data on the extremely fast on-board memory of 
graphics cards, potentially in an already preprocessed form. Currently two 
kinds of data are standardised: Vertex arrays and indices into those arrays. 
This is a rather cool mechanism, making some more specialised extensions like 
compiled vertex arrays (=> Quake :-) superfluous.

> > Furthermore you should do some hierarchical culling on the terrain
> > (using, e.g. a quad-tree) to avoid drawing things which are not visible.
> Too complicated for the practical course.  Doesn't OpenGL already do
> something like this?

OpenGL is intentionally designed as a *rendering* library, onto which 
higher-level libraries (e.g. Inventor) can be layered. Of course OpenGL 
throws away invisible primitives as fast as possible, but even this takes 
some time, so higher-level libraries can make OpenGL's life much easier.

> [...]
> > To summarize: Drawing vast terrains quickly has much more to do with
> > algorithmic cleverness rather than miniscule overheads from library
> > bindings.
> I did not refer to the overheads of the binding but to "the slowness of
> Haskell" (compared to C, of course ;-) ). [...]

I think this is one of the strengths of a Haskell binding for OpenGL: You can 
concentrate on the fun part (i.e. clever rendering algorithms etc.) much more 
easily than in C. Given the same amount of time, I imagine that one can 
implement much more elaborate stuff than in C, so you can actually get better 


More information about the Haskell mailing list