Opinions On The JOGAMP JOGL Status Quo

We're still using 1.1.1a at our site so it's been a while since we upgraded.  I recently started some experimental integrations of the JOGAMP JOGL distro to see what kinds of problems I could expect.  At first I tried the 2.0-rc1 release and was getting complaints and flaky behavior (windows refusing to close, seg faults, etc).  This was not encouraging, so I grabbed nightly build 300 and the situation improved dramatically.

So... the trend certainly is in the right direction, but I'm also interested in hearing observations from anybody who has been using JOGAMP's JOGL distro in fielded products.  Has it been stable?  Would you characterize it as generally "solid"?  Have you encountered any major missing or broken features that look like they'll be a while showing up?  That kind of thing.

Judging from his posts Wade Walker probably would have something to say assuming he's willing.  Anybody else?

FWIW I'm glad you guys picked up the ball and ran with it after the previous effort was abandoned, and I like where you're taking it for the most part.  I'm just trying to get a feel for how far along you are.

TIA for any feedback.

Rob

Hi Rob,

I have no problem commenting, though since I'm doing my best to try to help Sven, Michael and the gang with JOGL 2, I'm probably not objective

I think the decision about when to switch to JOGL 2 depends on what your requirements are. If you are an individual hobbyist or student, you should switch right now  And if your customers are all using relatively new computers, or if they are internal corporate customers using a well-defined set of computer types, you can probably switch now without encountering undue problems.

I think the only reason not to switch now would be if your user base includes lots of older (pre OGL 3) computers. I've seen some bugginess on those sorts of machines, and that's what I'm trying to help fix at the moment.

As far as missing features, one of the other guys may be more qualified to comment. But since JOGL 2 started out from the JOGL 1 code base, I don't think it's really missing anything that JOGL 1 had (except for a Solaris release).

On Friday, February 11, 2011 01:31:21 rhatcher [via jogamp] wrote:
>

Hi Rob,

I am the GlueGen/Joal/Jogl maintainer and general Jogamp lead,
the projects janitor, besides the many other valuable contributors
we gladly have allowing the project to become a success.

As Wade turns it out, sure we can't be objective,
but I try to do my very best to be :)

> We're still using 1.1.1a at our site so it's been a while since we upgraded.
> I recently started some experimental integrations of the JOGAMP JOGL distro
> to see what kinds of problems I could expect.  At first I tried the 2.0-rc1
> release and was getting complaints and flaky behavior (windows refusing to
> close, seg faults, etc).  This was not encouraging, so I grabbed nightly
> build 300 and the situation improved dramatically.
>
Our 2.0 release is not finished yet, still within RC state.
  http://jogamp.org/wiki/index.php/Jogamp_Versioning_and_Releases

We promote jogamp-next and webstart-next more often,
hence you might give this a try besides the auto-builds.

BTW we have a simple version applet available (webstart-next only for now)
  http://jogamp.org/deployment/webstart-next/applet-version-jnlp.html
dumping the the version information for your platform and the Jogamp modules.

I am on the same page with Wade, until 2.0 I would not recommend
a switch for your production stable build.

However .. development should use 2.*, since our new system provides
more quality in regards to testing, stability, besides features.
Of course, as Wade mentioned it, we cannot test all machines and configurations
and we all have our objectives here.
But if you are willing to participate, file bug reports, communicate
and maybe even triage and fix bugs - there is a good chance that we listen and change.
Together for sure we will be able to satisfy, which we cannot without knowing :)

Another great strategy for you to ensure important features are covered is
to provide unit tests which we can merge and hence run in our continuous integration system, Jenkins.
  http://jogamp.org/chuck/

Have I mentioned that there is no more Jogl 1* support ?

If you need more high priority support, more attention, etc,
feel free to contact the maintainers and/or other contributors for commercial help as well.
  http://jogamp.org/wiki/index.php/Maintainer_and_Contacts

> So... the trend certainly is in the right direction, but I'm also interested
> in hearing observations from anybody who has been using JOGAMP's JOGL distro
> in fielded products.  Has it been stable?  Would you characterize it as
> generally "solid"?  Have you encountered any major missing or broken
> features that look like they'll be a while showing up?  That kind of thing.

Speaking of commercial user, C3D a Java CAD kind of application, visualizing
construction zones etc, it uses the new JOGL 2 version due to it's performance requirements.
C3D uses NEWT's native window parenting to attach a NEWT / JOGL window to a Swing based UI
without AWT/Swings lack AWT-EDT pipelining.
The GL output, mouse/key input and AWT-EDT run independently using this solution.
Soon it will change to a ES2/GL4 modular rendering kit, asking for being deployed on mobile.

I am also aware that Nasa Worldwind is working on JOGL2 migration,
as well as other popular or 'important' projects.

Speaking of direction, the
 - OpenCL mapping JOCL
 - JOGL GL profile separation
 - Agnostic windowing system (NEWT)
 - Soon to be supported Android/Dalvik
 - QA via Jenkins, unit tests, Bugzilla and forum
 - and more ..

shall be convincing enough to start trusting Jogamp a bit, I hope.

>
> Judging from his posts Wade Walker probably would have something to say
> assuming he's willing.  Anybody else?

Everybody is free to talk here.

>
> FWIW I'm glad you guys picked up the ball and ran with it after the previous
> effort was abandoned, and I like where you're taking it for the most part.
> I'm just trying to get a feel for how far along you are.
>
> TIA for any feedback.

You are very welcome and thank you for your interest.

~Sven

>
> Rob
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://jogamp.762907.n3.nabble.com/Opinions-On-The-JOGAMP-JOGL-Status-Quo-tp2470518p2470518.html
> To start a new topic under jogl, email [hidden email]
> To unsubscribe from jogl, visit

Personally I have not had a lot of problems with JOGL 2 in development phase even on Windows by picking a convenient dev build. Maybe it is a bit early to use it in production. Sven has forgotten to mention that I ported some libraries/API to JOGL 2.0 including Ardor3D, JMonkeyEngine 3 and Nifty-GUI.

Speaking about the status quo of JOGL is a bit insulting on my view and totally wrong, it does not reflect the current situation of JOGL and JogAmp more generally.

JOGL 2.0 is solid enough to work in major projects except that there are some missing features in NEWT (as far as I know, the cursor cannot be removed), the GLJPanel (which has always consumed a lot of memory) is buggier than in JOGL 1.1.1a and disabling the auto swap buffer mode causes an high memory consumption too (which is a real problem in applications that need to display huge meshes).

Best regards

Edit.: My port of Ardor3D is there: http://ardorlabs.trac.cvsdude.com/Ardor3Dv1/ticket/201
My port of JMonkeyEngine 3 is there: http://code.google.com/p/jmonkeyengine/source/browse/#svn%2Fbranches%2Fjme3%2Fsrc%2Fjogl2
My port of NiftyGUI is there: http://nifty-gui.svn.sourceforge.net/viewvc/nifty-gui/nifty-jogl2-renderer/

All:

Thanks for the feedback - that's exactly what I was looking for and about what I expected to hear based on what I've seen so far in limited testing.

By asking about the "status quo" I only mean to see where the JOGAMP effort stands right now, and to gauge the group's general comfort level with the JOGAMP product since you guys are working on and/or with it every day.  Based on my initial experience with 2.0-rc1 I had cause to be concerned; however, between the group's feedback and the improved behavior of nightly b300 I'm feeling more encouraged.  It's always good to see Chuck Norris giving the thumbs up (our guys were greatly amused by that), but there is no substitute for anecdotal feedback from people working on fielded products.

I am reasonably tuned in to the history of this whole thing going back at least to GL4Java up through 1.1.1a being tossed out on the street, and the efforts at JOGAMP to put this product back on solid footing are greatly appreciated by those of use making significant use of Java and OpenGL.  Note that none of those comments are meant to diminish the contributions Ken Russell's group made to the prior product, and of course Sven before that with GL4Java.

Unfortunately for me our code base is large and a significant percentage of it is graphics code.  I'd need to covert the whole thing before I'd even know if it was fit to roll forward with.  Even though I can script most of the required changes I don't want to invest time in that until I feel like the chances are pretty good that it will either Just Work or any bugs I encounter will be easy to work around or fix.  It sounds like that would be the case.

Working in our favor is the fact that while we have a lot of OpenGL code none of it uses anything I'd characterize as advanced techniques.  There is a bunch of texturing and the occasional stencil buffer, but most of the rest is straightforward "stroke" type drawing.  Our installed production software base is small, most of the fielded hardware is relatively new and running some recent version of Fedora or RHEL, all of it is NVIDIA, and we always get to steer the hardware acquisitions for our customers.  Point being the target platform set is narrow, and probably one of the ones that is most likely to behave.

On the dicier side, there's a good chance we're going to transition our front ends to EclipseRCP/SWT at some point in the next 6 months, so how well JOGL2 works in that environment is a big factor in the timing of this transition.  I saw Wade has posted a few blurbs on this and I will be giving those a look shortly.  Some of the work you guys have done should result in a more straightforward integration with RCP.

Rob

Use my example too for Eclipse RCP, it works fine on Cent OS Linux 5.3, Windows Vista/ 7 / XP even with the debug pipeline.

rhatcher wrote

On the dicier side, there's a good chance we're going to transition our front ends to EclipseRCP/SWT at some point in the next 6 months, so how well JOGL2 works in that environment is a big factor in the timing of this transition.  I saw Wade has posted a few blurbs on this and I will be giving those a look shortly.

I've spent the last several years using JOGL 1.1.1a in a big RCP app at work, so feel free to ping me if you have any questions. My blog entries at http://wadeawalker.wordpress.com/ show how to set up a JOGL 2 RCP app in a similar way. And if you guys develop in Eclipse, https://jogamp.org/wiki/index.php/Building_JOGL_in_Eclipse walks you through the process of building JOGL 2 in Eclipse.

I've had some success building the SWT GLCanvas from source at home, so I may be able to contribute patches to help the integration with JOGL 2. Let me know if you guys run into any bugs in this area. Right now I'm looking at fixing multisampling on Windows, since that seems to be the best-known outstanding bug.

Wade/Julien, thanks for the pointers to the examples.  I definitely will look them over!

We do use Eclipse here and have had great luck with it, so I'll also take a look at Wade's related wiki article.  I did a little Eclipse plug-in development to support our general dev efforts, and that's what got me thinking how slick it would be to front-end our whole system with RCP.  I had to do some classloading work to bridge Equinox with our incumbent component management system, but once that was out of the way things started clicking into place (but that's getting off topic).  I initially feared that the limited early OpenGL support in SWT/RCP would kill the idea, but my later testing with JOGL 1.1.1a seemed to support everything we needed.  It's encouraging to hear that you've had some field experience with this combination and that it's been working well.

I'll be staying tuned in to SWT-related discussion on the forum and will try to participate on some level when time permits.

Rob