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.