com.sun.opengl.impl
Class GLBufferSizeTracker
java.lang.Object
com.sun.opengl.impl.GLBufferSizeTracker
public class GLBufferSizeTracker
- extends java.lang.Object
Tracks as closely as possible the sizes of allocated OpenGL buffer
objects. When glMapBuffer or glMapBufferARB is called, in order to
turn the resulting base address into a java.nio.ByteBuffer, we need
to know the size in bytes of the allocated OpenGL buffer object.
Previously we would compute this size by using
glGetBufferParameterivARB with a pname of GL_BUFFER_SIZE_ARB, but
it appears doing so each time glMapBuffer is called is too costly
on at least Apple's new multithreaded OpenGL implementation.
Instead we now try to track the sizes of allocated buffer objects.
We watch calls to glBindBuffer to see which buffer is bound to
which target and to glBufferData to see how large the buffer's
allocated size is. When glMapBuffer is called, we consult our table
of buffer sizes to see if we can return an answer without a glGet
call.
We share the GLBufferSizeTracker objects among all GLContexts for
which sharing is enabled, because the namespace for buffer objects
is the same for these contexts.
Tracking the state of which buffer objects are bound is done in the
GLBufferStateTracker and is not completely trivial. In the face of
calls to glPushClientAttrib / glPopClientAttrib we currently punt
and re-fetch the bound buffer object for the state in question;
see, for example, glVertexPointer and the calls down to
GLBufferStateTracker.getBoundBufferObject(). Note that we currently
ignore new binding targets such as GL_TRANSFORM_FEEDBACK_BUFFER_NV;
the fact that new binding targets may be added in the future makes
it impossible to cache state for these new targets.
Ignoring new binding targets, the primary situation in which we may
not be able to return a cached answer is in the case of an error,
where glBindBuffer may not have been called before trying to call
glBufferData. Also, if external native code modifies a buffer
object, we may return an incorrect answer. (FIXME: this case
requires more thought, and perhaps stochastic and
exponential-fallback checking. However, note that it can only occur
in the face of external native code which requires that the
application be signed anyway, so there is no security risk in this
area.)
Methods inherited from class java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
GLBufferSizeTracker
public GLBufferSizeTracker()
setBufferSize
public void setBufferSize(GLBufferStateTracker bufferStateTracker,
int target,
GL caller,
int size)
getBufferSize
public int getBufferSize(GLBufferStateTracker bufferStateTracker,
int target,
GL caller)
clearCachedBufferSizes
public void clearCachedBufferSizes()
Copyright 2005 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.