Memory Leaks
Status: Pre-Alpha
Brought to you by:
bryonh57
Since objects going into the dag are not smart
pointers, and since there will be some manipulations
(insertion and deletions) within the dag, there needs
to be some method of resolving ownership of pointers
to objects, who deletes them, and when.
Even with those in place, not carefully following the
guidelines through the system can result in massive
memory leakage.
Logged In: YES
user_id=120775
The scene class is the root node for all opal scene graphs
and repository for all scene assets. A SCENE can be
considered synonimous with a world. The scene object is
responsible for deleting out all objects in it. This works
by the culling mechanism running through the entire scene
and checking every pointer against the relocation table.
(We know this is present by the fSerialised flag being set
to 1.) As we run through the pointers we ask if it is in
the relocation table. If it is then we ignored it,
otherwise we determine if the memory is local. If it is
then we delete it otherwise a message will be broadcast
across the BUS<0,SCENE> event bus with the memory block
being attached that needs to be deleted by the owner.
Logged In: YES
user_id=120775
The scene class is the root node for all opal scene graphs
and repository for all scene assets. A SCENE can be
considered synonimous with a world. The scene object is
responsible for deleting out all objects in it. This works
by the culling mechanism running through the entire scene
and checking every pointer against the relocation table.
(We know this is present by the fSerialised flag being set
to 1.) As we run through the pointers we ask if it is in
the relocation table. If it is then we ignored it,
otherwise we determine if the memory is local. If it is
then we delete it otherwise a message will be broadcast
across the BUS<0,SCENE> event bus with the memory block
being attached that needs to be deleted by the owner.