Performance question

[thiagosc2]

Hi,

I am trying to develop a Swing application using JOGL and I am not being able to get a decent performance. My machine is quite obsolete, Pentium III 600 with a GeForce 2 and latest NVidia drivers, but this machine is enough to run Quake 3 or Soldier of Fortune 2!! So I suppose my application should run lightning fast.

I tried the JGears demo, and it runs at a decent speed. So I am not sure if my problem I see is just when using other Swing widgets.

I am using Java 6 beta2. The problem is that I set the parameter in the startup “-Dsun.java2d.opengl=true” and the overall speed of the application doesn’t seem fluidic enough. If I try to click in one of the menus or move a scrollbar I see some delays in the response. From the perspective of the user this is terrible.

I created a custom scenegraph structure and placed all the elements in there (a camera, a lookat transform, some translates, a light and a cube and the floor grid), and in the GLEventListener I just loop through it and call draw(GL) for each object returned. Nothing else, no culling, no sorting.

A new iterator is created each time, and the indices of vertices and edges are stored in ConcurrentHashMap objects. The methods of this structure as implemented are O(1).

The first question is:

• in the current state of Swing and JOGL should it be “lightning fast” with the menus, buttons and scrollbars with instantaneous response? So the problem is most likely in my code.
• I am not an expert in Swing, is active rendering only valid for fullscreen modes?
• if the rendering of the GLJPanel is taking too long could I just “slow it down” to say 30fps? How?
• what would be the sanest way of measuring the fps in a application like this? I have code doing it when it’s fullscreen and I use active rendering, but not sure how to do it when using Swing.

[Koen_Samyn]

It’s hard to say where the problem is without knowing what your application does and how it does it.

A couple of observations :

• I’d say the biggest problem is with Swing , not JOGL. You could replace GLJPanel with GLCanvas (the awt equivalent) and use awt for your application.

• Secondly you can use FPSAnimator to throttle the application.

• -Dsun.java2d.opengl=true is not necessary unless you want to draw something with Java2D. Some JOGL developers also turn of ddraw.

• Sanest and fastest way of measuring fps is to download fraps.

• another tip is that all open gl calls travel through JNI so it pays to use VBO’s,vertex arrays, display lists,…

Koen

[kbr]

@thiagosc2

I tried the JGears demo, and it runs at a decent speed. So I am not sure if my problem I see is just when using other Swing widgets.

Can you confirm whether you mean the Gears or the JGears demo? The former uses the heavyweight GLCanvas and the latter uses the Swing-compatible GLJPanel.

@thiagosc2

I am using Java 6 beta2. The problem is that I set the parameter in the startup “-Dsun.java2d.opengl=true” and the overall speed of the application doesn’t seem fluidic enough. If I try to click in one of the menus or move a scrollbar I see some delays in the response. From the perspective of the user this is terrible.

If you run e.g. the SwingSet2 demo out of the JDK with -Dsun.java2d.opengl=true how does it perform compared to without that command line option?

@thiagosc2

• in the current state of Swing and JOGL should it be “lightning fast” with the menus, buttons and scrollbars with instantaneous response? So the problem is most likely in my code.

It depends on your computer. The Java2D/OpenGL pipeline stresses different parts of the graphics hardware than most games as it uses either pbuffers or FBOs for its rendering. This means that your GeForce2 is very likely not going to accelerate the Java2D/OpenGL pipeline well. Things do seem pretty snappy with a reasonably modern card (even a GeForce FX 5000 series card should be fine).

@thiagosc2

• I am not an expert in Swing, is active rendering only valid for fullscreen modes?

It’s perfectly legal to use an Animator with a GLJPanel or to call display() on the GLJPanel manually. All thread safety issues are handled in the GLJPanel implementation.

@thiagosc2

• if the rendering of the GLJPanel is taking too long could I just “slow it down” to say 30fps? How?

You’d need to throttle back whatever animation mechanism you’re using to drive the GLJPanel. This would probably mean writing a custom Animator, or using the FPSAnimator, which lets you specify a desired target FPS (though it doesn’t let you change it on the fly – you need to stop and restart it at a minimum).

@thiagosc2

• what would be the sanest way of measuring the fps in a application like this? I have code doing it when it’s fullscreen and I use active rendering, but not sure how to do it when using Swing.

I usually just put timing code at the top of the GLEventListener’s display() method and after a certain number of calls to it divide the total amount of time taken to make those calls. This measures the “rest” of the application too; if you don’t want to measure that time you can just accumulate the time between the entry and exit of that method.

[thiagosc2]

This problem is solved. JOGL and Swing are performing ok in my machine, the problem was a bug in my code.