GLJPanel

OpenGL Development JOGL Development
#1

In the wee hours of the morning last night I finally got GLJPanel to work on windows using a pbuffer instead of software rendering. The results of running nehe’s lesson 6 as ported by k duling.

GLCanvas ~170fps
GLJPanel(pb) ~20fps
GLJPanel(dib) ~8fps

Who knew, copying an opengl framebuffer to system memory and then back to the card and dx really sucks the life out of an app.

#2

Any transfer operations are going to be AGP limited.
These days this is the tightest bottleneck in the graphics pipeline.

Additionally, graphics are optimized for write operations, and not so much for read operations (i.e. back to main memory).

This is one of the many reasons for the vertex and pixel shader development going on with all the chip/card makers.

#3 

55.4%     0  +   357    net.java.games.jogl.impl.windows.WindowsGLImpl.glReadPixels
 27.2%     0  +   175    sun.java2d.loops.Blit.Blit
  3.3%     0  +    21    sun.awt.windows.Win32BlitLoops.Blit
  3.3%     0  +    21    net.java.games.jogl.impl.windows.WindowsGLImpl.glClear
  1.2%     0  +     8    net.java.games.jogl.impl.windows.WGL.wglMakeCurrent
  1.1%     0  +     7    net.java.games.jogl.impl.windows.WGL.SwapBuffers

The rest of the methods are less than %1. This was on a all pci workstation so I assume results will be a little better on a machine with agp.

#4

Oh yeah, readPixels will kill ya, PCI, AGP, PDQ, XYZ doesn’t matter. You can do it, but you wouldn’t WANT to.

What’s on the card, stays on the card…one-way data flow, at least in the gaming world. In applications and such, the transfer hit may not matter as much.

#5

Would you be willing to post the code for using the pbuffer-modified NeHe lesson 6?

#6

You can check out some code here. Jogl.jar contains a working, at least for me, version of gljpanel that uses a pbuffer. There are a couple little demos posted.