jogl vs. lwjgl speed test

[DavidYazel]

I ran some speed comparisons against both API's.  The tests were of cubes being rotated an dtranslated around the screen.  Each cube has 16 triangles. Each cube is being rendered via vertex arrays in both api's.  

100 cubes:
lwjgl : 543 fps
jogl: 428 fps

300 cubes:
lwjgl: 237
jogl: 214

500 cubes:
lwjgl: 159 fps
jogl 150 fps

900 cubes:
lwjgl: 96 fps
jogl: 90 fps


I am gratified to see similar performance.  In the last test both were pushing close to 1 million triangles/sec.

[Markus_Persson]

Nice, thanks.  
Those numbers look pretty good.


Could you post the source code for the rendering loop from either and/or both?

[DavidYazel]

Well its a little hard to post a snippet since this is running in our Xith3d renderer off of a Java3d scenegraph.  The renderer is sitting at 12,000 lines of code as of tonight. (wow, I have been busy the last 2 weeks).

But basically the test scene is just two nested transform groups, one for rotation and one for translation.  So a mass of cubes are randomly placed around the origin and then the mass is rotated and translated on each frame

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

Random ran = new Random(35354);         for (int i=0;i<900;i++)         {             Shape3D shape = new Shape3D();             Appearance a = new Appearance();             a.setPolygonAttributes(new PolygonAttributes(PolygonAttributes.POLYGON_FILL,PolygonAttributes.CULL_BACK,0));             Geometry g = createCube(1-2*ran.nextFloat(), 1-2*ran.nextFloat(), 1-2*ran.nextFloat(), .5f, true); //            Geometry g = createCube(0.5f-ran.nextFloat(),0.5f-ran.nextFloat(),ran.nextFloat()-0.5f,0.5f,true);            shape.setAppearance(a);             shape.setGeometry(g);             tf_2.addChild(shape);             ShapeAtom atom = new ShapeAtom(shape);             r.addAtom(atom);         }

nothing special about the cubes.  I am not lighting them, just rendering them with vertex colors.  Since the engine sorts states and transforms and only switches the openGL states on changes we basically will have the following rendering pipeline:

1. setup view
2. set model transform
3. set polygon attributes
4. set rendering attributes
5. setup vertex array and draw

repeat step 5 for each shape, which is 900 in the last test case.

I am going to add an enhancement that detects duplicate geometry and sorts dup geometry seperatly, so we should be able to use the same vertex array over and over.. should be faster.

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

[gregorypierce]

Here is what I'll comment on JOGL vs LWJGL. The more time you spend rendering (i.e. a real game) the less performance difference you'll see between the two. JOGL and LWJGL are doing the native bits the most optimal way and the rest is all philosophy of API design. There is a bit more native code in LWJGL, but once things really get going - much of the benefit of some of its native bits starts getting lost in the shuffle just as Amdahl's Law dictates.

Amdahl's law states that the performance improvement to be gained from using some faster mode of execution is limited by the fraction of the time the faster mode can be used.    

[cfmdobbie]

Good to see that's pretty much what I'd expect!  LWJGL is a little faster due to its use of raw int pointers, but the difference isn't really much.

Now, will the numbers change with LWJGL 0.7?

[Matzon]

Now, will the numbers change with LWJGL 0.7?

Well, theoretically it should be more equal, however - since our native code is much leaner, I would still expect LWJGL to be faster...

[cfmdobbie]

Any wager on that?

Ah, much as people bemoan the redundant parallel effort, I do so love seeing competition!

[Matzon]

Tell you what, if LWJGL is NOT faster than any other general purpose binding, then I will make damn sure it is! - at least on the win32 platform... I am pretty sure that elias has the same feeling.

[Markus_Persson]

Speed's not everything, you know.

The main reason I'm switching to Jogl from LWJGL is partly to get rid of the weird native windows, and partly because it's more "official".

The opengl part of the rendering loop is rarely the bottleneck, so having 10-15% faster opengl calls doesn't really matter that much in a real app.
But it does make for pretty benchmarks.

[gregorypierce]

For any non trivial application I would actually be surprised to find a measurable difference in speed since most of the game (its controller paradigm, AI, gameplay... the game parts) are going to happen in common Java code.

With the actual bindings both using native byte buffers to pass large byte arrays to the actual opengl calls, the biggest bottleneck in an OpenGL binding is already out of the way. Having done a profile on a couple of my applications - outside of calling the actual OpenGL functions, my application spends most of its time in good old Java methods.

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

[Matzon]

But it does make for pretty benchmarks.

But since we can't compete on being more official, there is only API & speed left...

API wise, I think we win hands down - *much* simpler to use the LWJGL api, than using jogl et al. (bar documentation ).

So if we can be a bit faster and have a "better" API then I think we succeded - now we only have to get the other platforms (ie. Mac OS X) along too...

get rid of the weird native windows

Whats wrong with the window? - if we don't know what the users dislike, we cannot fix it...

[DavidYazel]

Heh and it bugged me that you cannot *get* the wierd native window in JOGL.

How many commercial games "fake" full screen by placing a window over the screen?  UH.. probably none.

Not to mention changing the display modes based on the user settings, not on the current display.

I like to play games at 1200 pixels wide, but I can't stand editing at that resolution.  Many people feel the same way.

I am glad to see that JOGL can actually draw the screen that quickly within an AWT window, I had worried that there migiht be some wierd buffering which would cost performance.

Basically with Buffer support for textures and geometry JOGL will always be in the running for shear speed.

[Markus_Persson]

Well, you can't set the icon on the window, you can't use it for anything other than OpenGL (like make it only use half the height for OpenGL and the other half for Swing), you can't resize it, you can't move it, and it insulted my sister.

Other than that, I guess it's fine.  

[size=1][Edit: I accidently invented "OpenLG"][/size]

[Matzon]

Well, you can't set the icon on the window, you can't use it for anything other than OpenGL (like make it only use half the height for OpenGL and the other half for Swing), you can't resize it, you can't move it, and it insulted my sister.

Setting the Icon: think we will implement this RSN, since others mentioned that too.

Yes, it is a OGL window only - if you need to mix and match with ordinary java components, you need to use jogl or gl4java - this is just a fact, since we'd prefer to not use any AWT stuff at all.

Resizing isn't possible, since it introduces a gazillion errors - and basically, most games don't need it!!

Moving window should be possible... works fine here - old release you tried last?

Insulted your sister??? - J/K?

LWJGL is for *gaming* - if you need a general purpose library, by all means use jogl or gl4java - but if you want a no frills simple api for getting a game running (windowed or fullscreen) using ogl, then LWJGL is your best bet!

[Markus_Persson]

I mean there's no way of moving the window from within the code. Sure, that's not exactly something you'd want to do.

The sister thing was a joke, yes.


But I agree about LWJGL being better than Jogl api-wise.
I really hope the Jogl people (ahem, nudge-nudge ) change their minds and open up the API a lot more. Having the only buffer swap being called when the only thread that can perform any GL commands returns is just.. strange.

[swpalmer]

But I agree about LWJGL being better than Jogl api-wise.
I really hope the Jogl people (ahem, nudge-nudge ) change their minds and open up the API a lot more. Having the only buffer swap being called when the only thread that can perform any GL commands returns is just.. strange.

Just curious 'cause I haven't done much of anything with OpenGL yet... Do you typically have a need to swap buffers in more than one place in your render loop?  When this "feature" of JOGL was described earlier I thought it made sense, even if it might be "weird" if you expected to be swapping the buffers manually.

[Markus_Persson]

Not in the rendering loop, no. But you can't for example have a method like this in Jogl:

1   2   3   4   5   6   7   8   9

public void init() {    for (int i=0; i<texturesToLoad(); i++)    {       loadTexture(i);       renderProgressBar();       swapBuffers();    } }

[gregorypierce]

LWJGL is most assuredly good Gaming API goodness - no one will ever be able to take that away, but there are somethings about the way it wants to do things that are annoying as well - such as Wurmonline trying to draw at the fastest refresh of the videocard when my LCD monitor cannot render at that refresh Would have been nice if there was an external configuration application for LWJGL so I could say *don't do this*...

Both of the APIs are going to have growing pains, but within a year I expect that people will be creating real games with both without issue.

[aNt]

yep! more of a 'jogl and lwjgl' then a 'vs' .

[vydias]

Not in the rendering loop, no. But you can't for example have a method like this in Jogl:

1   2   3   4   5   6   7   8   9

public void init() {    for (int i=0; i<texturesToLoad(); i++)    {       loadTexture(i);       renderProgressBar();       swapBuffers();    } }

That is why with jogl you would use another thread for resource loading and thus have the same effect as others have stated as a good idea.

1   2   3   4   5   6   7   8   9   10   11   12

public void init(GLDrawable drawable) {     loadTextures = new TextureLoader();     loadTextures.start();     ..... } public void display(GLDrawable drawable) {     if(loadTextures.LOADING)     renderProgressbar(drawable);     ........ }

[Markus_Persson]

That won't work. The other thread can't perform any OpenGL commands.

[vydias]

um, ok your right pass in GLDrawable to the threaded loader and there you go.

[Markus_Persson]

I fail to see how that would help..

[tortoise]

Is it possible to have more than one GLUpdateListener going at the same time? If so, wouldn't that solve the problem?

[Markus_Persson]

Nope, the DrawableHelper will call display on all the listeners before returning to invokeGL in the GLContext, where the swapBuffers() is performed.

(in other words, display() on all the listeners must return before the buffers are swapped)

[vydias]

Maybe I'm missing something here but in the Threaded example I only need access to the GLDrawable to load in the textures.

If this is threaded why can I load textures in a seperate thread and set an animator to start the openGl rendering and only break into my progressbar rendering as textures are being loaded?

[Markus_Persson]

glDrawable.getGL()?

Does that work on both linux and windows for you?

[vydias]

I only develop for windows initially so I don't know about linux.  After I have a windows version any code that needs porting i.e. our exe (autoudates, checks jvm version sets paths ecodes all java files, etc..) and our actually game code will be ported at that time.

So if this doesn't work under linux that is good to know but it isn't a very big concern for those working with this under windows which IMO is probably the vast majority of developers.

[gregorypierce]

And if it doesn't work, that's a bug that should be dealt with and not something that you should be trying to code around.

[Markus_Persson]

Then what's all this I keep hearing about the only legal place to perform opengl calls is in the invokeGL method in GLContext?