Dewey Anderson (dewey++at++evt.com)
Tue, 16 Apr 1996 15:57:50 -0700
This is Performer 2.0 on an Onyx with RE 2.
Basic flow of the program is:
create a basic scene
Loop:
create a few textures & put them on rectangles.
Create a pfNode for each with DCS-SCS-rectangle (all unique)
attach them to the scene
pfuDownloadTexList( pfuMakeSceneTexList( (scene), PFUTEX_APPLY );
fly them around some
for each node
detach it from scene
pfDelete the node
I noticed that after doing this a number of times (dependent on the amount of
texture), the call to pfuDownloadTexList crashes deep in a bcopy. I get the
impression that texture memory has filled up and that's causing the crash.
This made me figure that the pfDelete must not be clearing the textures from
texture memory. I took a look at the refCounts and noticed that when I go into
my draw callback (which does nothing but call pfDraw), the refCount on the
pfTexture is 1 but after the call to pfDraw, that refCount has gone up to 2.
This only happens during the FIRST call to pfDraw in the "fly around some"
animation loop. (It remains 2 thereafter.)
Is this correct that drawing an object with a texture counts as an ADDITIONAL
reference to that texture? Is there some Performer protocol or convention that
I'm not following that would make the general flow work, i.e. delete the
texture when I'm done with it?
OK, next comes the kludge fix. I stuck in an unref right after the texture
gets applied to the rectangle:
gstate->setAttr( PFSTATE_TEXTURE, tex );
tex->unref(); // FIX: kludge to keep ref count low enough
Printing out the refCount now shows 0 going into the draw callback (probably
not recommended practice, I know...) and 1 after the pfDraw. This did not
solve the problem making me think that maybe just doing a pfDelete on the
pfNode isn't enough to make it walk down the branch and delete the texture from
texture memory. Do I need to explicitly pfDelete the pfTexture to clear it out
of texture memory?
Any help is appreciated.
Dewey Anderson
Evolving Video Technologies
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:43 PDT