How GLJPanel works

OpenGL Development JOGL Development
#1

Hello everyone!

I’m a GL4Java user and am moving to JOGL.

I’d like to know how JOGL integrates with Swing. Specifically, how GLJPanel works. From what I know by looking at GL4Java’s source, I remember it copies the card’s framebuffer back to system memory. This has serious performance drawbacks obviously. I’m wondering if JOGL uses the same method for GLJPanel?

My reason for using GLJPanel is because I need to draw Swing components on top of some complex geometry rendered by OpenGL. Therefore AWT is not an option.

Thank you for any information for this JOGL newbie! :slight_smile:

.rex

#2

Please ignore my above question.

I’ve installed JOGL and gone through the API docs. GLJPanel currently does not support hardware-acceleration, so my question is pointless as of now.

So my new question is: When will GLJPanel implement hardware-acceleration?

Thanks!

.rex

#3

[quote]So my new question is: When will GLJPanel implement hardware-acceleration?
[/quote]
I’ve added it to the list of things to do but it is currently low priority as it seems most people are successfully using the GLCanvas. All of the required pbuffer support is in the public API at this point so if you’d like to take a crack at it it will get done faster. You can also feel free to file an RFE about this issue if there isn’t already one.

#4

Having GLJPanel would be nice so I could sit renderers in internal frames and not have to play rendering games so they don’t overlay lightweight controls :slight_smile:

#5

Due to the architecture of Swing, one needs to copy the OpenGL framebuffer back to system memory and then copy it to the Swing component’s own image buffer.

My many experiences with reading back the hardware framebuffer tells me that it is incredibly slow, due to the asymmetrical design of AGP. System memory to video memory is fast, but video memory to system memory is slow. 15fps at 640x480x32bpp is about the best I got. However, shared memory systems, like those embedded 3D chips in notebook computers are different. They do not seem to go thru AGP, but instead thru PCI, and the video memory to system memory speed is much higher than AGP.

So it seems to me that integrating OpenGL with Swing is going to have serious performance issues, using the current method. GL4Java does it, and JOGL seems to be going that way too.

Being ignorant in the inner workings of Swing and OpenGL, may I boldly suggest doing things the opposite way: copying Swing components’ images from system memory to video memory to composite/blend with OpenGL’s framebuffer?

.rex

#6

Would the pbuffer implementation still use a bufferedimage? I thought the whole bottleneck was moving the array across the bus a couple times, not the one copy from the pbuffer to texture memory. It seems tome that if you could somehow turn the texture ref into the source for a volatile image that would be the best solution. I may be totally wrong but that was my impression of the problem.

#7

The bottleneck is a hardware issue: the bandwidth of AGP. AGP allows you to write to video memory at its advertised speed (4X, 8X etc.), but it never publicly told you that reading from video memory is not as fast, but more like 10 times slower.

This has come as a nasty surprise for a lot of people who one day found the need to use a lot of glReadPixels().

Please, try it yourself. Do a simple test of glDrawPixels and glReadPixels and compare the difference in speed.

.rex

#8

It seems to me that as long as you have to send the image from the card to a bufferedimage in system memory and then back to the card every frame that hardware acceleration of the rendering won’t result in much of a speed up. With Java3d I usually got around 1/10th the fps with a offscreen image and profiling of the app pointed to image copying as the slowest section of code.