#683 Declined
  1. GOD

The original idea was to register objects with unique ids across the lifetime of the session.
In turn it was helpful in analyzing and debugging complex issues as we now have:

  1. A unique ID for an object
  2. The Creation order for the objects.
  3. Object creation timestamp.

In addition it is used to solve a very old issue regarding inconsistency while rendering transparents.

Comments (3)

  1. Eugene Golushkov

    While this code may be useful for debugging - it should not be part of the Ogre, as it increases size of the every allocated objects by 16 bytes. Moreover, Ogre already has MemoryTracker used under #if OGRE_MEMORY_TRACKER by StdAllocPolicy

  2. GOD author

    Memory tracking is irrelevant to the goal of this PR.
    Other than debug capabilities, having a unique ID allows to:

    1.Pinpoint the timing of the creation of the object in relation to other objects.
    There are several uses for real runtime use (no debug), I gave here one as example where it's used to solve a very old bug (from 2002) where transparent objects are being rendered inconsistently if they have the same depth.

    2.Currently all registration of objects is made internally by the memory address of the object, e.g (size_t)mVIewport and it works.
    But sometimes it is useful to register/unregister objects from outside of Ogre without tracking the creation / deletion of an object - "garbage collect".
    This is impossible with the current design since all I have is the memory address of the object which may belong to several objects in a meaningful period of time (longer than a single point in time).


    • The mTimeStamp is there for added value and it's not a must, so it could be only 8 bytes instead of 16. I'm not entirely sure how of an issue the extra memory usage is.
    • This could remove the need for NameGenerator to generate unique names.
    1. Eugene Golushkov

      Lior, other programmers should not pay for features they don`t use.

      Here is the sample, how this feature can be introduced without adding overhead for those that would not use it. 1. Create AllocationPolicyWithMetadata
      2. Create specialization AllocatedObject<AllocationPolicyWithMetadata> with all additional necessary fields.
      3. Create CMake option and define that will enable this allocation policy.

      But even then, there is overhead of supporting rarely used features.

      Regarding memory usage - iPad2 has significant market share among iOS devices, 512MB of RAM shared with all other apps, and no page file. Mobile world is very sensitive to memory usage.