In OpenGL, the following command is used to create a new Quadric Object: qObj = gluNewQuadric(); And, to delete it, we have: gluDeleteQuadric(qObj); In HOpenGL, to create a new Quadric, the command is: qObj <- newQuadric But how do I issue deleteQuadric? Its signature is: deleteQuadric :: QuadricObj -> Addr -> IO () but I don't know how to use it. What is this "Addr" parameter for? -- Andre
Andre W B Furtado wrote:
[...] In HOpenGL, to create a new Quadric, the command is:
qObj <- newQuadric
But how do I issue deleteQuadric? [...]
Simple answer: Never! :-) The garbage collector automatically takes care of this via the ForeignObj mechanism (well, this should be ForeignPtr or something in future versions). deleteQuadric is oly use internally and not exported, anyway. examples/redbook_HS/Quadric.hs demonstrates the usage of quadrics in HOpenGL. Tesselators and NURBS are not explicitly deleted, either, BTW. OTOH, I must admit that I haven't used GLU's quadrics, tesselators, and NURBS extensively yet. They are quite a moving target in different OpenGL versions, but things have settled down a bit recently. As always, API critique and suggestions are highly welcome. Cheers, S. -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de
Sven Panne wrote:
[...] The garbage collector automatically takes care of this [...]
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? Does this apply to display lists also? (Does the GC takes care of unused display lists?) Thanks, -- Andre
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.
participants (3)
-
Andre W B Furtado -
Sven Panne -
Sven Panne