Performance of LWJGL vs JOGL

[Vorax]

I managed to get  my code updated to use LWJGL instead of JOGL.   I have one version of each at the moment - exactly the same code, except the GL API calls.  I have everything setup to do performance testing since I was already doing that before switching to LWJGL.  The test is a single scene in a game I am working on that pushes the engine hard.  The GL calls to render it cover a broad set and it has a high vertex count.  This isn't a full fledge benchmark of course, or I would need numbers on the calls, verts, etc...but it's a realistic test based on typical usage.

The results:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16

Tested using AMD 2600+, 512MB RAM, nVidia Geforce 5700OC, 256MB (latest drivers) 1) FPS - No shadows             JOGL |  LWJGL --------------------------------------------------------   800x600:    140 |  155 1024x768:     100 |  110 2)  FPS - With full scene dynamic stencil buffer shadows (1 light source)             JOGL |  LWJGL --------------------------------------------------------   800x600:    50 |  51 1024x768:     35 |  35

The engine is very optimized.  For JOGL, the code has been profiled every which way from sunday using numerous tools checking everything from memory to CPU.  Rendering is sorted using an optimized hash algorithm that works specifically with the types of state changes, material, texturing etc that you would want to avoid.  The reason I decided to try out LWJGL is because the biggest bottlenecks I could find (that could possibly be optimized)  where now in JOGL iteslf (not the GL calls, but the API). 

I have yet to optimize the code for LWJGL.  I expect there is a fair amount I can do because so much of the API uses NIO, where my original code was using java arrays for many of the calls (except VBO's and Vertex Arrays which in JOGL also use nio buffers).  I am sure I am allocating buffers that I don't need to, etc.  in the current LWJGL version.

Bottom line - I am impressed with LWJGL. 

[princec]

And so you should be Elias & Spasi & Matzon have worked long and hard to make it better than everything else 

Cas

[Ken Russell]

Are you running full-screen or windowed mode?

If you're running on Windows, does specifying the system property -Djogl.GLContext.nofree have any effect on the performance of the JOGL version?

Games published by our own members! Check 'em out!

[Vorax]

Are you running full-screen or windowed mode?

If you're running on Windows, does specifying the system property -Djogl.GLContext.nofree have any effect on the performance of the JOGL version?

The tests were done in windowed mode.

I tried the switch and got the following exception:

net.java.games.jogl.GLException: Error making context current: 127
   at net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(WindowsGLContext.java:153)
   at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:125)
   at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:248)
   at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.invokeGL(WindowsOnscreenGLContext.java:79)
   at net.java.games.jogl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:236)
   at net.java.games.jogl.GLCanvas.display(GLCanvas.java:77)
   at com.vorax.VoraxEngine.doGameLoop(VoraxEngine.java:459)
   at com.vorax.VoraxEngine.startGame(VoraxEngine.java:430)
   at com.vorax.VoraxEngine.engineLoop(VoraxEngine.java:922)
   at Pacifica.main(Pacifica.java:87)

[Ken Russell]

I think the difference in frame rates is probably due to the fact that LWJGL leaves its AWTGLCanvas's OpenGL context current on the AWT event queue thread. while JOGL releases it after each frame for correctness purposes. JOGL's nofree option (which emulates this behavior and is a workaround for memory leaks in ATI's Mobility Radeon 9700 drivers) seems to work for me and if you are willing to try to diagnose why you're getting the error please contact me via PM.