Ardor3d speed jogl vs lwjgl

This is the second time I have changed from lwjgl to jogamp. Other than a few initialization routines (JoglSwtCanvas vs LwjglCanvas) and the ardor3d jars (Ardor3D-master_2016_01_22 vs ardor3d-0.8). Obviously I am running under SWT in an Eclipse environment. Java version 1.8.0_91.  The same Ardor3d code runs painfully slower under jogl. Just like last time, my boss is clamoring to make me change back to lwjgl. Any suggestions?

A bit of context. I create a 3d environment (land and buildings) from a design created in the other part of our software. We import COLLADA models. I have no control over the design or the models, so it could be a small environment or a large one. Sight lines are all the way across the environment. Due to processing issues (in the past) water features do not have active waves, but they do reflect the sky. There are also shadows, which are turned off when moving.

So, same code, same input, same design, same machine, different Ardor3d libraries, jogamp is slower than lwjgl. A quick response would be appreciated since I am under pressure to change back.

Hi

At first, keep in mind that we do our best on our spare time, we're not paid to do that. You can ask something, you cannot and mustn't demand it. The pressure is for you, not for us even though I don't want to abandon you.

JogAmp's Ardor3D Continuation is actively maintained (and supports only JOGL) whereas the legacy Ardor3D was abandoned several years ago. Your boss wants you to use an abandoned piece of software, there is no way back to the other set of bindings you mention.

Moreover, the legacy Ardor3D relied on an obsolete version of L****, it doesn't support L**** 3. If something goes wrong, you'll have to port the old semi-broken legacy version to L**** and you'll have to maintain it yourself.

Have you tried other SWT canvases provided by JogAmp's Ardor3D Continuation? com.ardor3d.framework.jogl.swt.JoglNewtSwtCanvas?

I cannot find the culprit without seeing your source code.

N.B: No, JogAmp is about 3% faster than L**** but there is probably something not working correctly elsewhere.

P.S: Please don't mention L****, this is none of my concern.

At first, how do you use the frame handler? Calling syncExec isn't necessary.

Secondly, please compare what is comparable. JoglSwtCanvas just wraps an heavyweight JOGL SWT GLCanvas whereas L****Canvas was comparable to JoglNewtCanvas. That's why I advise you to use JoglNewtSwtCanvas.java, look at the sub-project ardor3d-jogl-swt. If it doesn't work fast enough, use JoglAwtCanvas with the SWT_AWT bridge. I used the very last option in an Eclipse RCP software and it worked but I had to do something special to avoid breaking the debug mode.

How much slower?

Something is wrong, first thing you should do is trying to profile code to check where is the bottleneck.

Netbeans have an integrated profile, but also other IDEs should have something similar.

Profiling the code this way helps if the bottleneck is on the cpu side.

If you can't find it, then you should use gpu timers to profile the OpenGL side, like shown in this small sample

Thanks for all the help. NEWT solved the problem. It actually is so much faster that it caused a problem for me. In the old code, when accelerating, I got one frame per autorepeat keystroke (key event).  NEWT sometimes does an extra draw between key events so, according to my program, I was not moving during that draw. I fixed it by adding padding to how long after a key event movement is reported.

You can detect autorepeat events in NEWT:
http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/newt/event/InputEvent.html#isAutoRepeat()