Damn @$#^%%&^%

[Java Cool Dude]

Ok I've been introduced to JoGL by a fellow javagaming member not that long ago, and I was definitely charmed by the fact that I can go down to the byte level unlike other APIs such as Java3D.
Anyways I started making ports to compare performance between the demos once written in Java and the original C++ code.
To my surprise the JoGL ports were slightly faster than the original C++ demo.
That's before I ran into some demos such as CellShading and HeightMap rendering:
Basically the frame rate was cut in HALF and sometimes even lower.
So I started taking off bits of code here and there to finally narrow the circle of suspicions to the "for" loops.
Indeed looping takes huge chunks of time everytime it's called in Java, to the point of EMBARASSMENT .
Check the code in the JoGL forum and you'll definitely notice the rather poor performance of the said ports due to Java slow loops...
Also that depressing observation can be noticed in every demo that requires a lot of polygon drawing such as Quake 3 Loader and Animators.
In case of the loader, we're dealing with still Models so we can call a display list to avoid continuous looping but unfortuantely it is near impossible to use such approach when it comes to animation.
/me off to cry a bit :-/

[princec]

'sfunny, I've never had a problem with loops...

Cas

[Mojomonkey]

Do these for loops contain your code to render you object? And if so, are they calls to glVertex, glNormal, etc? If so, your penalty could be JNI overhead rather than the loops themselves. Because these demos are rendering a lot more vertices that overhead is becoming more apparent. If you are rendering in this way, i.e. glBegin/glEnd block, you should look into VBO or vertex arrays. This will require a few calls (1 for vertices, 1 for colors, 1 for texture, etc) each rendering cycle rather than thousands for each vertex.

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

[cfmdobbie]

Yeah, you would have thought that any glaring performance problems with "for" loops would have been spotted by now...

Microbenchmark time, methinks!

[princec]

Java Cool Dude, run with -Xprof and post it up here and we'll find out how to fix it.

Cas

[Java Cool Dude]

One example
So yes, I'm thinking the native call to opengl functions is what slowing the ports to hell.
See the demos that ran better on Java than C++ only called glVertex3f, glNormal3f...very few times, enough to draw a cube or a simple 3D shape.
The example I posted up above draws huge maps by calling their vertices and textures coordinates. The level of complexity of the mentioned map as well as the delay in calling the native functions explains the huge slow downs that I'm pointing out.
Oh well I can still call vertexArrays and Display lists

[cfmdobbie]

Yep, tunneling lots of calls through JNI to OpenGL will be a performance killer.  It's not even a good idea in C/C++ land, although the effect is a lot less.  Using glBegin/glEnd and lots of glColor/glVertex/glNormals etc is generally referred to as "immediate mode".

Make good use of the batching features of the API - use vertex arrays, display lists, VBOs etc.  With a bit of luck your bottleneck will move somewhere else!

[princec]

That code's a great way to show somebody how to draw terrain really slowly but it shows you the worst possible way to do it in OpenGL and Java.

Cas

[Markus_Persson]

Actually, Wurm STILL uses very immediate mode rendering as well..

I was going to fix it a long time ago, but it turned out the biggest bottleneck was fillrate in forests. Drawing thousands of large billboards is an efficient way of stabbing performance in the face.

But Soon(tm) I will finally implement the occlusion test, and move everything into VBOs (or vertex arrays, if VBOs aren't availabe). Muoahaha. *rubs hands*

[edit:]
Oh, and the closest trees will be models instead of billboards. I need to cut down on fillrate, AND models look better.