JOGL limitations?

We have to decide whether to develop a new (large) application and framework using either a C/C++ with OpenGL approach or a Java/JOGL approach.  Being a long-time Java developer (and just because it would be really cool to get it working entirely in Java), I naturally would prefer to take the Java/JOGL approach but I am concerned about potential limitations inherent in taking such a direction.

Firstly, performance.  I am thinking that the performance of the rendering would be no slower using Java than C/C++ because it will be governed more by the capabilities of the GPU in use.  Is that correct?  I mean, is there any reason why I should be expecting significantly poorer performance from a Java-based OpenGL application than a C/C++ one?  Of course in areas where the application is running pure Java (i.e. not GUI or rendering related) then I know what to expect but I am not sure about the rendering side of things.

Secondly, the ability to utilise the full capabilities of OpenGL.  Are there any limitations with the JOGL approach in this area?  That is, are there things I could do with OpenGL using C/C++ that I cannot do using JOGL?  Some aspects of shading, GLSL etc. perhaps?  Maybe JOGL is limited in its ability to access all OpenGL extensions?  I am just guessing here.

Finally, are there any limitations in other areas that I haven't thought of?

Your input would be much appreciated and I would especially appreciate hearing from Michael and/or Sven.

Thanks,

-Qu0ll

>Firstly, performance.  I am thinking that the performance of the rendering
>would be no slower using Java than C/C++ because it will be governed
>more by the capabilities of the GPU in use.  Is that correct?

Yep that is correct. As rendering is performed 100% by the native driver and on the GPU there is no overhead using JOGL in that respect. But there are some areas on the Java side where overhead is implied:

1. Native OpenGL-API calls using JNI (JOGL uses JNI to foreward native calls) have an overhead. But this overhead is very small and doesn't really matter in a real application coz too many API calls kill your OpenGL performance anyway (even in C/C++) and if you stay under a couple of hundred calls per frame u won't notice the difference.
2. Datatransfer to the GPU has some overhead (see 1.) but by programming carefully and using NIO u can limit the peformance impact. Also it does only matter when tranferring large chunks of data every frame.
3. There is some overhead implied with the window toolkit u choose to display ur OpenGL output. For further information see here: http://jogamp.org/wiki/index.php/Jogl_FAQ#Why_using_AWT_for_high_performance_is_not_a_good_idea_.3F This is ofcourse also an issue when using C/C++ so u can't really compare JOGL/Native C++ there.

Anyway the way u program OpenGL today is more or less "upload data->init shaders->let the GPU render the stuff->control/modify output with shaders" so the JOGL/API call or any other Java overhead doesn't really matter for rendering performance anymore.

>Secondly, the ability to utilise the full capabilities of OpenGL.  Are there any
>limitations with the JOGL approach in this area?  That is, are there things I
>could do with OpenGL using C/C++ that I cannot do using JOGL?  Some
>aspects of shading, GLSL etc. perhaps?  Maybe JOGL is limited in its ability
>to access all OpenGL extensions?  I am just guessing here.

To my knowledge currently the only limitation is that u can't use GL4 feature like geometry shaders/hardware tesselation (wich is in the works right now as far as I'm informed). Other than that there's really no limit to what u can do with JOGL. Vertex/Fragment shaders and extensions are ofcourse fully supported.  

For a small overview of stuff u can do with JOGL from the simplest fixed function pipeline flat shaded torus using OpenGL 1.0 up to completely GPU based particle systems and Parallax-Occlusion-Mapping using OpenGL 3.1 features take a look here: http://www.youtube.com/user/DemoscenePassivist#g/c/9725BF2AF5A18CD9

Hi Demoscene Passivist,

Thanks very much for your input.

What you say about rendering performance is encouraging.  I am not totally clear about the windowing toolkit options however.  Ideally I would like to be able to produce an applet version of at least part of our application so I am guessing that limits us to using some kind of (slow?) AWT integration.  Is that correct?  On the desktop we are not so limited and can choose any windowing toolkit.  What are our options there?  It is clear that using Swing is going to reduce performance so what else is there for wrapping a JOGL application?

BTW, your demos are very impressive.  Some of them are a bit jumpy/choppy and I am not sure if that is inherent in the performance of the demo or whether it's just the video that's choppy.

Thanks,

-Qu0ll

>Ideally I would like to be able to produce an applet version of at least part of
>our application so I am guessing that limits us to using some kind of (slow?)
>AWT integration.  Is that correct?

So far I've only seen JOGL applets using AWT. A couple of month ago Sven stated in his blog stg about eliminating the need to use AWT for applets: "I will show a NEWT-AWT applet demo, and later, after finishing the AWT-Less plugin feature, we don’t even need to use AWT anymore." http://jausoft.com/blog/2009/07/03/jogl-applets-part-1/ But I don't know how far that implementation has progressed since.

Anyway I wouldnt overestimate the impact of AWT vs. NEWT in a common single threaded single rendering window application. As stated in the FAQ a real performance penalty only arises when u use AWT with mutliple threads rendering to multiple windows so that the surface locking mechanism "blocks" the other threads. So saying AWT+JOGL is "slow" is a little bit exaggerated :)

To give u an impression what performance to expect using AWT or better JOGL in general take this simple vertex shading example http://www.youtube.com/user/DemoscenePassivist#p/c/9725BF2AF5A18CD9/22/VovI20JntjQ on my NVidia Geforce 8800M GTX (average notebook GPU) it runs at an average of 1400 FPS in 1280x1024.

Also u should note that with the javax.media.nativewindow infrastructure provided with JOGL2 u can easily switch between window-toolkits with little implementation work on ur side.

>On the desktop we are not so limited and can choose any windowing toolkit.  
>What are our options there?  It is clear that using Swing is going to reduce
>performance so what else is there for wrapping a JOGL application?

Personally I'm using AWT for all of my experiments on the desktop. Mainly because I'm using the Fullscreen-Exclusive-Mode feature of AWT to get correct vertical sync. Thats a feature NEWT is lacking at the moment but for normal window-mode rendering I guess "AWT is ok for single threaded single rendering window applications" and "NEWT is better when using mutliple rendering windows and threads".

But I would NOT recommend using Swing/GLJPanel. If u are a really dedicated Swing lover u can get it to work correctly but without going further into the details if u want to stay out of trouble avoid using the GLJPanel. The main reason is that u often loose hardware acceleration under various environments wich is ofcourse completly unacceptable performance wise.

>BTW, your demos are very impressive.  Some of them are a bit jumpy/choppy
>and I am not sure if that is inherent in the performance of the demo or whether
>it's just the video that's choppy.

The "choppyness" comes from the recompression when uploading the video to youtube. When running the demos live in realtime most of them are running in a couple of hundred fps without v-sync and when enabling v-sync u get ofcourse rock solid 60 fps.

ps. Michael and Sven are currently on the Siggraph 2010 to do some pr-stunt for jogl/jocl. So have a little patience :)