i experience quite bad thing when repeatedly loading movie textures.
it is one video file. and i construct and destroy the frame as neccessary. for each time i construct, i get about 7 megs system memory, and 2 meg of graphics memory consumed.
after some minutes of clicking , compiz crashed and my desktop fell back on the metacity window manager. was somewhere in the 200 megs or so, starting from 6. restarted compiz and the panda app, and my frame-time doubled and got very laggy.
it ran very fine until it crashed my desktop.
i am not getting any extra geoms or nodes so those are cleaned up as they should.
same happends with other geometry (all with textures) that i load and reload. so it is not limited to directgui. most of the memory seems to gather in “never Free”
any clues what goes wrong? anything i can try to get more detailed info on the problem? using daily builds from mid-november. ubuntu 10.04, 64bit
I’m a little unclear about the precise nature of the problem. You mention movie textures, but then you describe creating and destroying geometry. Is it the movie textures, or the geometry, that appear to be leaking? Or both?
You can drill further into the “never free” category and usually get specific information about the memory type, especially if you have “track-mem-usage 1” in your Config.prc file (but don’t enable that if you use threads).
Have you tried temporarily disabling the geom cache with “geom-cache-size 0”? How about “graphics-memory-limit 0”?
ah. ok , first off. i am an idiot. i used remove() on the directGUI frames. using destroy actually fixes all the movie and texture related leaking.
so now i am left with the only the geometry. this happens for all geometry i load, no matter if generated by code, or loaded from disk. but so far i was unable to reproduce the leaking in an isolated test case.
will continue to investigate. probably something in my code… somewhere…
ok once more. disregard my last statement.
apparently, it originates from my textnodes which i create along with pretty much every geometry.
and now comes the interesting part.
i use (almost) the same code for generating textnodes for 2 things.
in one case i reparent the textnode to an directframe that remains fixed.
removing the frame works fine here.
is my other case, i reparent the textnode to a directbutton. and there is a task updating the buttons position every frame.
so i had aspect2d.directButton.mytextnode
when i destroy the button, i remove() the task, then destroy() the button. but the textnode didnt get freed.
if i never start the position-updating tasks. it gets freed properly.
and please excuse my windowsitter. talking about pstats, it sorta inverted the whole diagram, as you can see.
i know it aint much memory for a single textnode. takes bout 50 nodes for a single meg. but it sums up in my application pretty fast as i create about 20 of them each time the user touches the screen.
no need for immediate panic, but it would be nice to know whats going on. especially as it seems to work perfect without the task updating the positions.
ok. i managed to fix the thing.
in my removal function i had to delete my own reference to the positioning task by self.posTask = None
i still don’t get why everything gets cleaned up ok without the textnode in it. i mean, task or not, it should clean up the vertex-data once the node is gone, right?
Absolutely. So the fact that it failed to clean up the vertex-data implies that the node itself wasn’t destructed, either.
This isn’t surprising–if you have a cyclical reference, like self.posTask which contains a task which contains self, then the entire object will never be deleted, including anything it contains.
i totally didn’t see that that cylindrical reference. thx for pointing out. such a silly mistake of mine. i feel like facepalming about myself.
that also explains why a previous version of this implementation did not show this. there i added the tasks, but i searched the taskmanager to find and delete the task. instead of storing it in a class variable.
.png)
i mean, task or not, it should clean up the vertex-data once the node is gone, right?