[Haskell] GLUT gears speed

Sebastian Sylvan sebastian.sylvan at gmail.com
Mon Jan 16 09:16:25 EST 2006


On 1/16/06, Wolfgang Jeltsch <wolfgang at jeltsch.net> wrote:
> Am Freitag, 6. Januar 2006 22:17 schrieb Wolfgang Jeltsch:
> > Hello,
> >
> > what's the reason behind the HOpenGL gears only being about 2/3 as fast as
> > glxgears on my computer?  Since I don't use any 3D acceleration, I thought
> > that most of the CPU's time is spend for rendering and displaying so that
> > speed differences between Haskell and C shouldn't matter that much.
> >
> > Best wishes,
> > Wolfgang
>
> Hmm, no reply until now. :-(
>
> A related question:  I plan to let "my" students write some HOpenGL based
> applications in a practical course whose intend is to train them in
> functional and logic programming.  One of these applications should simulate
> a flight over a landscape whose surface is modelled via fractal brownian
> motion.  So the program needs to display a rather large amount of geometric
> primitives and needs to do this rather fast because the thing is animated.
> Now my question:  Is Haskell in conjunction with HOpenGL overstrained with
> this problem or can I expect the application to run fast enough to not make
> the students laugh about Haskell's speed. :-)  Of course, the program should
> be run only on graphic cards with 3D acceleration.
>
> I'd be happy about quick replies. :-)

As long as you don't do it naively there should be no problems. I.e.
do not draw the terrain using the vertex-calls, but rather use
vertex-arrays, or (better) vertex buffer objects. Furthermore you
should do some hierarchical culling on the terrain (using, e.g. a
quad-tree) to avoid drawing things which are not visible. Also, some
sort of level-of-detail-scheme is probably a good idea (blocks of
terrain far away have lower level of detail).

To summarize: Drawing vast terrains quickly has much more to do with
algorithmic cleverness rather than miniscule overheads from library
bindings.
You may want to find a good terrain-rendering library rather than
implementing it yourself.


/S

--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862


More information about the Haskell mailing list