Testing validity of vertex buffer objects

OpenGL Development JOGL Development
#1

I’m using the JSR-231 code and vertex buffer objects in rendering. When I resize the window they become invalid and I must re-initialise them.

I’ve been looking at how to do this efficiently. A call to gl.glGetBufferParameterivARB(…) takes about 28 micro seconds (using System.nanoTime()) but I wish to reduce that. If I understand it right, with JSR-231 jogl the GL context will remain valid across all calls to the display function, although all work will get executed on one thread. I have seen where the drawable.getGL() is the same across multiple display calls, but it changes after resizing.

My question is, can I reliably (supporting best practices) hold on to the GL context from within the init function, and use this in my display method (ignoring the drawable.getGL()), and then check to see if this is different, to know when to re-initialise my vertex buffer objects

#2

Well I tried it, and it works, but I don’t know if this is a best practice.

Intrestingly, the test of the gl context:

gl.equals(oldgl)

takes 6 micro seconds. I expected less, but it still is better. than the call to gl.glGetBufferParameterivARB(…) .

#3

Are you using the GLJPanel? Resizing a GLCanvas should not cause any re-initialization.

The recommended way to do this is to set up things like VBOs and textures in your GLEventListener.init() method. This is the primary purpose of this callback.

#4

Yes, I’m using the GLJPanel and when I resize the panel the init method gets called again

#5

GLJPanels use Pbuffers to do rendering and Pbuffers can’t be resized. So every time you resize your GLJPanel it is destroyed and a new Pbuffer is created, thus the reinit. Maybe we need a little pbuffer associated with every GLJPanel that will keep your old resources around and then create new Pbuffers with shared resources.

#6

Remember this is JSR-231. I thought that pBuffers were not used anymore for GLJPanels

#7

The only situation in which the GLJPanel can avoid the use of pbuffers is when running with Mustang and -Dsun.java2d.opengl=true. In any case there will continue to be situations in which it has to fall back to using pbuffers, for example when stencil bits are requested which are not supported by Java2D’s chosen pixel format. You need to restructure your application to properly handle multiple calls to init() as described in the JOGL Users’ Guide.

#8

I’m using JSR-231 and -Dsun.java2d.opengl=true.

Inbetween calls to init does the GL object remain, so I can test against this. The way my code is structured the point I’m noticing this only gets a drawable to render to.

#9

I really advise against looking at the GL object’s identity. We don’t strongly specify its semantics and if some other piece of code does something like plug in a DebugGL pipeline under the hood then your code will be wrong. Can’t you just set a boolean flag in your init() method and test that later rather than testing the identity of the GL object?

#10

Yeah. It might be faster also. Thanks.