Controlled buffer swapping

OpenGL Development JOGL Development
#1

Hello,

Ive been using the Jun for Java Opengl binding for my application.

I converted my it to use jogl in less than two hours (very cool). So far everything seems to work except for one of my picking methods. It renders to the back buffer and uses glReadPixels to determine the color of the pixel at the cursor. It then maps back to the 3d object that was rendered in the color.

To accomplish this I need to have the ability to abort the call that swaps the back buffer to the front buffer at the end of rendering. I don’t want to render the “pick mode” buffer to the screen, just get the pixel color.

I’m considering extending the necessary classes and creating a factory class, to add this functionality. Is this the way I should do it, or is there a better way?

Thanks,
Gregg

#2

Hi, I also have a beef with with the way the buffer swapping
is done in JOGL. It does the swap for you, after it calles
GLEventListener.display()! This has been problematic for
me to - it broke my XOR graphics update system on the
Sun computers (which JOGL doesnt seem to work well on right now anyway) because the hardware there does a pointer swap rather than a buffer copy for glSwap(). So my code wrote onto the front buffer for an XOR updates on the Suns. Also I would like to be able to defeat a swap entirly if my code can determine there was really no reason to do an update. Did you subclass your own GLCanvas?

#3

I ended up creating 5 classes. GLCanvas can’t be subclassed because it’s declared final.

The classes are CameraGLCanvas, CameraGLContextFactory, CameraGLContextHelper, CameraOnscreenGLContext, and CameraWindowsGLContextFactory. All these classes correspond to the existing jogl classes for Windows.

I haven’t looked at the other implementations, but I think it might be a fairly simple matter to add a boolean to the existing classes to check before swapping buffers. If it’s true do the swap, false don’t swap. Maybe we can get it added in the future.

I can send you the code if you want it. The changes are minor. I don’t see a way to attach files here but I don’t mind emailing it to you.

Gregg

#4

I have to chime in here and agree. It causes me significant problems with some client code I’ve been working on where I need to have more fine grained control over when the buffer swaps and the solution in JOGL isn’t quite ideal. As I started digging through the JOGL source I discovered that it doesn’t HAVE to be this way, but is more a convenience thing the way it is implemented.

Not sure the current design is the best for applications that need more swaps than one per frame.

#5

Hi Gregg, I’d love to see your improved code. I’m at
shenness@scripps.edu

Sean

#6

Hi Sean,

Here’s a rundown of what I changed.

CamerGLCanvas - I had to change GLCanvas because it used a factory class to create its context. Since it’s final I can’t override anything. It uses CameraGLContextFactory and CameraGLContextHelper.

CameraGLContextFactory - I changed this one so it would return CameraWindowsGLContextFactory as the factory class.

CameraGLContextHelper - This one is because GLContextHelper has package scope.

CameraOnscreenGLContext - This is the one that actually controls the SwapBuffer call. It extends WindowsOnscreenGLContext. I used the NoAutoRedrawMode boolean as the logic switch. This probably is an inappropriate use of this boolean but it works for now.

CameraWindowsGLContextFactory - This returns an instance of CameraOnscreenGLContext.

As a temporary solution, I directly instantiate CameraGLCanvas instead of using a factory. i.e. glCanvas = new CameraGLCanvas(glCapabilities, null, null);

I think that’s it.
Gregg

PS: I emailed the code to you.

#7

Please file an RFE describing what you were trying to do (with the code if at all possible) and why the current JOGL APIs weren’t sufficient. Thanks.