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:
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. 