Acceleration variants in GLJPanel?

[Saxer]

I’m currently writing one chapter of my diploma-thesis about the improvements which were made to the GLJPanel.

I want to write especially about this “software rendering -> pbuffer -> fbo”-chain.

So here my questions:

• Does software-rendering simply read-back the pixels via glReadPixels and paints it to the Graphics-Object which was passed by (where does the context come from)?
• What’s the benefit of the pbuffer-variant. (That’s what I understood from http://192.18.37.44/forums/index.php?topic=10813.0
• Do you “just” pass the swing-backbuffer as the buffer to render to when the fbo-codepath is enabled? (Thats what I understood from http://weblogs.java.net/blog/campbell/archive/2005/09/java2djogl_inte_1.html)

I don’t need the concrete implementation. So alle the sanchronisation and so on isn’t needed within the chapter. For the general overview 3-4 sentence about the “software rendering -> pbuffer -> fbo”-chain would be great. I already inspected the source-code but I got lost wihtin all those boolean-flags ;D

Thanks in advance
Klemens

[kbr]

@Saxer

I’m currently writing one chapter of my diploma-thesis about the improvements which were made to the GLJPanel.

I want to write especially about this “software rendering -> pbuffer -> fbo”-chain.

So here my questions:

• Does software-rendering simply read-back the pixels via glReadPixels and paints it to the Graphics-Object which was passed by (where does the context come from)?

Please study the source code. You’ll learn more and be able to answer your own question.

@Saxer

• What’s the benefit of the pbuffer-variant. (That’s what I understood from http://192.18.37.44/forums/index.php?topic=10813.0

It provides hardware acceleration for the OpenGL portion of the rendering pipeline.

@Saxer

• Do you “just” pass the swing-backbuffer as the buffer to render to when the fbo-codepath is enabled? (Thats what I understood from http://weblogs.java.net/blog/campbell/archive/2005/09/java2djogl_inte_1.html)

The Swing backbuffer is implicit. It’s the OpenGL drawable associated with the current OpenGL context.

@Saxer

I don’t need the concrete implementation. So alle the sanchronisation and so on isn’t needed within the chapter. For the general overview 3-4 sentence about the “software rendering -> pbuffer -> fbo”-chain would be great. I already inspected the source-code but I got lost wihtin all those boolean-flags ;D

I apologize for the complexity, but if you put in some printouts and run some examples you should be able to figure out which code paths are taken and which aren’t.

I’ll be happy to answer questions, but you need to write your own thesis…

[Saxer]

Well of course I have to ;). I didn’t want to appear sluggard.

So I’ll try to answer my questions from what I’ve learned so far (I hope you can correct my anwers in case of I’m wrong):
Without pBuffers and FBO’s pixels are just read back from OpenGL into an BufferedImage (offscreenImage) which is then paintet into the passed Graphics-Object

With pBuffers the OpenGL-Operation is able to act in it’s separate hardware-accelerated context the rest is very similar to the simple case (offscreenImage and so on)

With FBO’s enabled you “simply” have to fetch the desired FBO-Number from the GLContext (the Pipeline has “put” it in there) and bind it. After that all the registered GLEventListener of the GLJPanel get their display()-Callback to render into the FBO. Any paint to the passed Graphics-Object isn’t needed because the pixel-data has already been inserted into the FBO.

I hope I’m right with these answers.

Thanks Klemens

[Saxer]

I found this nice PDF which helped me to understand more of the code. http://download.nvidia.com/developer/presentations/2005/GDC/OpenGL_Day/OpenGL_FrameBuffer_Object.pdf. Unfortunately I still don’t know where the Java2D-system begins with it’s FBO work. Maybe it’s non public code. In my imagination there should be a glBindFramebufferExt-call within the Java2D-class. While this class shippes with the jogl.jar and the pipeline works without jogl too (am I right), I think there should be a portion of code somewhere within the jdk. Could you point me to the particular class (if there’s one out there)?

I’m writing my chapter based on the pdf peppered with some little code references. So the mentioned code where Java2D actually starts it’s work is the only thing missing.

[kbr]

@Saxer

I found this nice PDF which helped me to understand more of the code. http://download.nvidia.com/developer/presentations/2005/GDC/OpenGL_Day/OpenGL_FrameBuffer_Object.pdf. Unfortunately I still don’t know where the Java2D-system begins with it’s FBO work. Maybe it’s non public code. In my imagination there should be a glBindFramebufferExt-call within the Java2D-class. While this class shippes with the jogl.jar and the pipeline works without jogl too (am I right), I think there should be a portion of code somewhere within the jdk. Could you point me to the particular class (if there’s one out there)?

The code which does this is on the Java SE side. Note that the Java2D class in JOGL calls in to certain private methods in the Sun-private OGLUtilities class in Java SE in order to do its work. The method names are reasonably descriptive (“invokeWithOGLContextCurrent”, which runs a Runnable with the OpenGL context associated with a given Graphics object current, for example). These methods are exported from the Java2D class over to the GLJPanel which consumes them.

The OGLUtilities class is under src/share/classes/sun/java2d/opengl/OGLUtilities.java and it has a lot of backing native code under src/share/native/sun/java2d/, in particular under opengl/, and platform-specific native code under e.g. src/windows/native/sun/java2d/. I don’t know the Java 2D source base, only the interface we defined for the Java 2D / JOGL bridge, so can’t provide much more information than this.