[HOpenGL] Quadrics

[Sven Panne]

Andre W B Furtado wrote:
> So if I have an idleFunc (or timerFunc) that has the following command:
> 
> qObj <- newQuadric
> 
> and if it's called a lot of times I sould not worry about the heap, souldn't
> I?

We should handle quadrics, tesselators, and NURBS objects similarly,
because they are all structs/classes in the GLU C binding, which are
created and destroyed in the same manner. The sizes of these objects
in the SGI sample implementation on Intel-Linux are:

   GLUquadricObj     20
   GLUtesselator   3140
   GLUnurbsObj   140812   (Huh?! I hope I got this one correct...)

I didn't expect the latter ones to be so large, so relying on Haskell's
GC alone might not be the best thing. Here's a suggestion for improvement:
In analogy to Haskell's file handles, add explicit "destructors", which
*can* be used explicitly (e.g. in your case), but needn't if you don't
care about the exact time when the associated resources are released.
For convenience, a "withFOO" action could be added, too. So, e.g. for
quadrics:

   newQuadric    :: IO QuadricObj
   deleteQuadric :: QuadricObj -> IO ()
   withQuadric   :: (QuadricObj -> IO a) -> IO a

Although withFOO would be the minimalistic interface, looking at the
different GLU implementations reveals that apart from the allocation
alone there is a lot of initialization going on internally (at least
for tesselators and NURBS). This could be a performance killer if you
are forced to allocate a new object every time you need one. But that
is only a guess.

Comments?

> Does this apply to display lists also? (Does the GC takes care of unused
> display lists?)

Display lists are another story: There are not much resources associated
with themselves (at least if I read the SI/Mesa code correctly), and there
is deleteLists. GC alone can not determine if a display list name will be
used in the future, but perhaps there is a way I didn't see yet...

Cheers,
   S.