From: Dimi (christop++at++fhw.gr)
Date: 04/04/2002 04:22:27
Hi,
I am still "fiddling around" with dynamic loading of Scene graphs :),
and I have come around another strange problem.
First thank you for your previous replies concerning deleting pfFluxes.
They were very helpfull.
What I run now into is that I have a class which creates billboards
(using pfBillboard) and loads up the textures which are mapped onto that
billboards. I load the textures using the pfNewSharedTex function, in
order
to optimize pfTexture usage.
Strangely I noticed that there was a big memory leak whenever I used
that function.
When I used the loadFile member function of a previously created
pfTexture ther was no memory leak.
Fortunately this function belongs to the pfu... classes of performer
which are open source.
So I went inside the pfuTex.c file (which had the function) and tried to
find the memory leak.
I found that the leak was occuring when a pfCopy was invoked inside the
pfNewSharedTex
function. The original algorithm used was:
The function first allocates a static pfTexture object (I dont know
why).
Then loads the image file into that object (using pfLoadFile).
If all went OK, it created a new pfTexture and used pfCopy to copy the
static object
onto the new one.
After that it added the new one to the internally holded list and
returned it.
Changing the algorithm a bit (essentially removing the pfCopy) stoped
the leak.
I know it makes no sense that a pfCopy should produce a memory leak,
maybe its another performer bug.
I verified this by minitoring the shared arena usage and using
gmemusage.
Is there anything I dont take into account, or is it a real performer
bug.
Hope you can help me.
Dimi
--
Dimi Christopoulos {christop++at++fhw.gr}
VR Software Engineer
Foundation of the Hellenic World
Athens - Greece
This archive was generated by hypermail 2b29 : Thu Apr 04 2002 - 04:20:57 PST