Ogre::ArrayMemoryManager::RebaseListener Class Reference

When mUsedMemory >= mMaxMemory (that is, we've exhausted all our preallocated memory) ArrayMemoryManager will proceed to reallocate all memory. More...

#include <OgreArrayMemoryManager.h>

Inheritance diagram for Ogre::ArrayMemoryManager::RebaseListener:

Public Member Functions
virtual void	applyRebase (uint16 level, const MemoryPoolVec &newBasePtrs, const PtrdiffVec &diffsList)=0
	Called when the manager already grew it's memory pool to honour more node requests. More...
virtual void	buildDiffList (uint16 level, const MemoryPoolVec &basePtrs, PtrdiffVec &outDiffsList)=0
	Called when the manager needs to grow it's memory pool to honour more node requests. More...
virtual void	performCleanup (uint16 level, const MemoryPoolVec &basePtrs, size_t const *elementsMemSizes, size_t startInstance, size_t diffInstances)=0
	Called when too many nodes were destroyed in a non-LIFO fashion. More...

Detailed Description

When mUsedMemory >= mMaxMemory (that is, we've exhausted all our preallocated memory) ArrayMemoryManager will proceed to reallocate all memory.

The resulting base pointer address may have changed and hence each ArrayVector3, ArrayMatrix4, etc needs to be rebased (alter it's mChunkBase pointer).

It consists in two steps: First build a list of relative differences before deallocation and then apply the new base offseting based on that list. The list is needed because as per C++ standard, once the memory freed, using the pointers is undefined behavior (even freedPtr > someValid pointer is now UB). Most systems using a flat memory model in which case the list wouldn't be needed (since 99% of the times, the ptr is just an integer). However we can't guarantee in which architectures this code will run on.

Member Function Documentation

applyRebase()

virtual void Ogre::ArrayMemoryManager::RebaseListener::applyRebase ( uint16  level, const MemoryPoolVec &  newBasePtrs, const PtrdiffVec &  diffsList  )

pure virtual

Called when the manager already grew it's memory pool to honour more node requests.

Remarks

Will use the new base ptr and the list we built in

See also

buildDiffList() to know what mChunkPtr & mIndex needs to be set for each ArrayVector3/etc we have.

Parameters

level	The hierarchy depth level
newBasePtrs	The new base ptr.
diffsList	The list built in buildDiffList

Implemented in Ogre::ObjectMemoryManager, Ogre::NodeMemoryManager, and Ogre::BoneMemoryManager.

buildDiffList()

virtual void Ogre::ArrayMemoryManager::RebaseListener::buildDiffList ( uint16  level, const MemoryPoolVec &  basePtrs, PtrdiffVec &  outDiffsList  )

pure virtual

Called when the manager needs to grow it's memory pool to honour more node requests.

See the class description on why we need to do this (to avoid C++ undefined behavior)

Remarks

Needs to builds a list that will contain the difference in bytes between each ArrayVector3/ArrayMatrix4/etc and the base pointers in_the_order in which the derived class holds those pointers (i.e. in the order the SceneNodes are arranged in memory)

Parameters

level	The hierarchy depth level
basePtrs	The base pointers from each pool so we can calculate the differences
utDiffsList	The list we'll generate. "outDiffsList" already has enough reserved space

Implemented in Ogre::ObjectMemoryManager, Ogre::NodeMemoryManager, and Ogre::BoneMemoryManager.

performCleanup()

virtual void Ogre::ArrayMemoryManager::RebaseListener::performCleanup ( uint16  level, const MemoryPoolVec &  basePtrs, size_t const *  elementsMemSizes, size_t  startInstance, size_t  diffInstances  )

pure virtual

Called when too many nodes were destroyed in a non-LIFO fashion.

Without cleaning up, the scene manager will waste CPU & bandwidth on processing vectors & matrices that are not in use. The more fragmented/unordered those removals were, the worst it is. Try to create everything static first, then dynamic content.

Remarks

The manager behaves similarly to a Garbage Collector, as it is triggered after certain amount of nodes have been freed (unless they respected LIFO order)

In a way, it's very similar to vector::remove(), as removing an element from the middle means we need to shift everything past that point one place (or more).

Parameters

level	The hierarchy depth level
basePtrs	The base ptrs.
startInstance	The instance to which past that we need to shift
diffInstances	How many places we need to shift backwards.

Implemented in Ogre::ObjectMemoryManager, Ogre::NodeMemoryManager, and Ogre::BoneMemoryManager.

---

The documentation for this class was generated from the following file:

• OgreArrayMemoryManager.h