Posted by
Sven Gothel on
Feb 02, 2012; 9:13pm
URL: https://forum.jogamp.org/JOGL-slows-down-after-extended-use-tp3705684p3711268.html
On 02/02/2012 07:02 PM, gouessej [via jogamp] wrote:
Our state tracker are essential for security measures.
GLBufferStateTracker identifies the bound buffer object.
- It validates it's access state (VBO enabled/disable)
e.g. for VertexAttribPointer calls when using VBO or not.
- It also tracks the buffer size for the actual MapBuffer call
which is required and predetermined by BufferData.
Another HashMap of type MemoryObject then stores
the adress, size and the actual NIO memory object to be reused.
the latter allows covering multiple memory 'windows' in one
and reducing the number of costly NIO objects and calls.
- Above state objects are bound to the GL/GLContext instance
and 'freed' with the destruction of the GL/GLContext object.
I currently fail to see further side effects.
- The GL spec does not allow us to free the resources at an
earlier point. UnmapBuffer could be used though, but a usual
application may like to reuse the [NIO] buffer object.
We may could introduce an addition entry point
where the user explicitly releases memory bound objects.
Currently this would be the GLContext destruction.
- Resume: This tracker is essential and more a boost to JOGL's
performance than slowing down baggage. Of course, if you can
give use cases w/ test code to reproduce showing
inefficiencies or even bugs, we shall fix it.
GLStateTracker is a simple GLContext bound int/int hash map
providing very fast access to client sides pixel states (16 values).
It is very unlikely this tracker slows down anything or even
causes a memory leak.
In my humble opinion, these trackers should be used only
> in debug mode, not in production :s
see above, both, especially the former is an essential core component.
W/o it we could not implement the GL functionality [properly].
~Sven