performance problems using GLJPanel

OpenGL Development JOGL Development
#1

Hello,

In my terrain editor, i’m using swing components: JButtons, JSlidebars, ect. So, I read about GLJPanel, and i thought to build in.
I replaced this code:
canvas = GLDrawableFactory.getFactory().createGLCanvas(new GLCapabilities());

to this:
canvas = GLDrawableFactory.getFactory().createGLJPanel(new GLCapabilities());

and may fps is 3 now. Using GLCanvas the fps was around 150-200.

How can i resolve it?

thank!

#2

Are you using the new JOGl 1.1 b08 ?

#3

yes, i donwloaded today.

#4

Could you run with the system property -Djogl.verbose specified and post any output? In particular, you should look for the output

“GLJPanel: Falling back on software rendering due to pbuffer problems”

Also, what CPU, OS and graphics card are you running with?

#5

I tried using -Djogl.verbose, and I received this:
“Using single-threaded workaround of dispatching display() on event thread
Using single-threaded workaround of dispatching display() on event thread
Using single-threaded workaround of dispatching display() on event thread
Using single-threaded workaround of dispatching display() on event thread
Using single-threaded workaround of dispatching display() on event thread
Using single-threaded workaround of dispatching display() on event thread
Using single-threaded workaround of dispatching display() on event thread”
7x the same string… What does it mean?
My system is a WindowsXp SP2 with and ATI Radeon9600XT and Catalist5.1
and Java 1.5.0_01.

#6

Using GLCanvas, I received this output with -Djogl.verbose
“Using single-threaded workaround of dispatching display() on event thread
Using single-threaded workaround of dispatching display() on event thread
Using single-threaded workaround of dispatching display() on event thread”

…
I tried the new 5.2 ATI driver released 2005.02.09, but the result is the same.
Hopefully, You can help me to find the solution for this performance problem.
Thanks.

#7

I almost forgotten to say, that using GLJPanel the program startup is slower with 75%. It might be usefull info…
But no “GLJPanel: Falling back on software rendering due to pbuffer problems” message running my software.

#8

Is it possible for you to boil down your program into a test case where you can switch between the GLCanvas and GLJPanel versions with a system property and file a bug with the JOGL Issue Tracker?

I definitely see poor performance of the new GLJPanel on my ATI Radeon 9800 but haven’t had a chance to try to speed it up. I suspect that the glReadPixels() call that is very fast on NVidia cards is much slower on the ATI card.

#9

I tried the JRefract demo, and it runs slow too. Slower than the original Vertex Program Refract demo.
My simplied program has the same performance problem.
What i haven’t done yet?

By the way, using GLJPanel should be faster the GLCanvas?
2x? 3x? …

#10

What is the JOGL Issue Tracker? It is a bug report site?
I should put my simpliest code to this bug report?

#11

GLJPanel will definitely be slower than GLCanvas as it involves a read back of the frame buffer and a data copy to the screen. We are hoping to get better Java2D / JOGL integration in 1.6 which would accelerate this process and make them close to identical speed, but that is a way off.

The JOGL Issue Tracker is linked off the main JOGL web page on the left hand side.