stuck in Processing with with any JOGL release >= RC6 (Mac)

Hey guys,

Since a few months ago, I have been using in Processing a set of JOGL jars that I build myself right before RC6. With all the RCs starting from RC6 onwards, OpenGL Processing sketches on Mac OSX (10.6+) would just give an null pointer exception right after displaying the first frame or even before the output window is visible on the screen. The full error stack is the following:

java.lang.NullPointerException
        at processing.mode.java.runner.Runner.findException(Runner.java:652)
        at processing.mode.java.runner.Runner.reportException(Runner.java:597)
        at processing.mode.java.runner.Runner.exception(Runner.java:537)
        at processing.mode.java.runner.EventThread.exceptionEvent(EventThread.java:367)
        at processing.mode.java.runner.EventThread.handleEvent(EventThread.java:255)
        at processing.mode.java.runner.EventThread.run(EventThread.java:89)
Exception in thread "Animation Thread" java.lang.NullPointerException
        at javax.media.opengl.awt.GLCanvas.validateGLDrawable(GLCanvas.java:555)
        at javax.media.opengl.awt.GLCanvas.display(GLCanvas.java:398)
        at processing.opengl.PGL.requestDraw(Unknown Source)
        at processing.opengl.PGraphicsOpenGL.requestDraw(Unknown Source)
        at processing.core.PApplet.run(PApplet.java:1860)
        at java.lang.Thread.run(Thread.java:680)

Processing can use either AWT or NEWT, but the problem happens with both. I was holding on to update JOGL to more a more recent RC hoping that this issue would go away in the meantime, but it didn't. I also run tests with jar files I built from the latest revision from the git repo, and the result is still the same.

It seems to me that something fundamental in the way the GL drawable is handled on OSX changed with RC6, and this has broke OpenGL rendering in Processing ever since.

I'm pretty much stuck with this one at this point, any hints on what to look for will be appreciated.

Thanks,
Andres

Hi

It would be fine if Processing used the same kind of threading than Ardor3D. This one still works fine with NEWT, AWT, NEWT with an AWT bridge, SWT...

The context is available later than with JOGL 1 but I think this change happened before the RC6.

On 07/13/2012 12:03 PM, ac [via jogamp] wrote: This can only happen w/ AWT's GLCanvas.

 at javax.media.opengl.awt.GLCanvas.validateGLDrawable(GLCanvas.java:555)

> I was holding on to update JOGL to more a more recent RC hoping that this issue
> would go away in the meantime, but it didn't.

It would be better, if you shoot me a message ASAP when things are broken!
Well, can you point your fingers to the earliest commit/[pre-]release which
broke things ?
Pls give me detailed instruction how I can reproduce this.
I will look into it and hope we can fix it.

It is one goal to have processing running very well
w/ current JOGL on desktop and mobile (Xerxes).

+++

I finalize the FBO stuff now, see bug 599.
Your MSAA hack should not be required anymore after 599 is solved.

+++

~Sven

Sven is right. If you could find which revision causes this problem, it would help us to understand what is wrong.

> Processing can use either AWT or NEWT, but the problem happens with both.

How do you activate NEWT in processing?

When i test Processing i test the latest Processing 2.0 release against the latest JogAmp current release.

wget http://processing.googlecode.com/files/processing-2.0a6-linux.tgz
tar zxvf processing-2.0a6-linux.tgz
cd processing-2.0a6/modes/java/libraries/opengl
wget http://jogamp.org/deployment/jogamp-current/archive/jogamp-all-platforms.7z
7z x jogamp-all-platforms.7z
mv jogamp-all-platforms/jar/*.jar library
cd ../../../..
#the java bundled with processing do not work on ARM so i move it away and let the processing use the system installed java.
mv java java-x86
./processing

By doing this i am able to see spinning P3D cubes on my ARM Cortex-A9 based Toshiba AC100 using the nvidia tegra 2 drivers.

cheers
Xerxes

@sven:

> It would be better, if you shoot me a message ASAP when things are broken!
> Well, can you point your fingers to the earliest commit/[pre-]release which
> broke things ?

Sorry for the delay in reporting the issue, but I was thinking that maybe I did something wrong and really didn't much time to look at it until now. I will try to locate the earliest commit that triggers the problems.

> This can only happen w/ AWT's GLCanvas.

Yes, the error message is from the tests with AWT. The outcome is not entirely consistent, as sometimes I get the exception and some other times the Processing sketch just doesn't show up without any error. When I switch to NEWT, I only observe the latter behavior

@gouessej

> It would be fine if Processing used the same kind of threading than Ardor3D.

Thanks for the suggestion, I will take a look at the Ardor3D initialization code, maybe it give me some idea of what is wrong. Another tricky thing with this issue is that when I run the OpenGL sketches as a stand-alone application in Eclipse which just depends on the core and opengl Processing packages, it works (with all RCs up to 9). So there must be something related to the way the Processing environment initializes the sketches. but since I cannot reproduce in Eclipse it makes debugging more difficult...

@xerxes

> How do you activate NEWT in processing?

In the PGL.java file in the opengl package, change the value of the toolkit static variable from AWT to NEWT and rebuild.

On 07/13/2012 11:23 PM, ac [via jogamp] wrote:
> @sven:
>
>> It would be better, if you shoot me a message ASAP when things are broken!
>> Well, can you point your fingers to the earliest commit/[pre-]release which
>> broke things ?
>
> Sorry for the delay in reporting the issue, but I was thinking that maybe I
> did something wrong and really didn't much time to look at it until now. I
> will try to locate the earliest commit that triggers the problems.

Thank you. A detailed instruction how I can reproduce this bug
would be great as well - ofc.

>
>> This can only happen w/ AWT's GLCanvas.
>
> Yes, the error message is from the tests with AWT. The outcome is not entirely
> consistent, as sometimes I get the exception and some other times the
> Processing sketch just doesn't show up without any error. When I switch to
> NEWT, I only observe the latter behavior

You mean w/ NEWT it always:
  (a) it crashes but no error is being shown ?
  (b) it works ?

.. sorry .. the double negation always makes my brain fail :)

If you can reproduce the bug, pls also add all the debug flags
related: "-Djogl.debug=all -Dnativewindow.debug=all -Dnewt.debug=all"

A dump of the log file (attachment to bug report), would be helpfull.

~Sven

I isolated the commit that broke opengl rendering through AWT in Processing. It is the following:

http://jogamp.org/git/?p=jogl.git;a=commit;h=3ed491213f8f7f05d7b9866b50d764370d8ff5f6

The null pointer exception doesn't occur all the time, but roughly in 1 out of 5 runs. As I mentioned earlier, the error message that I get in the console is:

java.lang.NullPointerException
        at processing.mode.java.runner.Runner.findException(Runner.java:652)
        at processing.mode.java.runner.Runner.reportException(Runner.java:597)
        at processing.mode.java.runner.Runner.exception(Runner.java:537)
        at processing.mode.java.runner.EventThread.exceptionEvent(EventThread.java:367)
        at processing.mode.java.runner.EventThread.handleEvent(EventThread.java:255)
        at processing.mode.java.runner.EventThread.run(EventThread.java:89)
Exception in thread "Animation Thread" java.lang.NullPointerException
        at javax.media.opengl.awt.GLCanvas.validateGLDrawable(GLCanvas.java:555)
        at javax.media.opengl.awt.GLCanvas.display(GLCanvas.java:398)
        at processing.opengl.PGL.requestDraw(Unknown Source)
        at processing.opengl.PGraphicsOpenGL.requestDraw(Unknown Source)
        at processing.core.PApplet.run(PApplet.java:1860)
        at java.lang.Thread.run(Thread.java:680)

I don't know how to pass the JOGL debug flags to Processing right now, but I will find out soon and add the full log information.

As for NEWT, the test sketch run without any apparent problems, at least in 10 consecutive runs using the same jogl jars I generated from the commit in question

I opened a bug including the debug log:

https://jogamp.org/bugzilla/show_bug.cgi?id=606

On 07/14/2012 06:40 AM, ac [via jogamp] wrote: Thank you, hard work that was - KUDOS.
That proofs that the recursive lock was required, and the volatile barrier is
not satisfying here. Makes sense, will revert the locking part
and also add it for the remaining GLAutoDrawable (GLJPanel).

Must have missed the scenario, where GLCanvas's lifecycle isn't completely
being handled by AWT's EDT :)

> I don't know how to pass the JOGL debug flags to Processing right now, but I
> will find out soon and add the full log information.

When I was testing for mobile, I just added them to one of your property
files, guess there was a 'runtime' JVM property line ..

>
> As for NEWT, the test sketch run without any apparent problems, at least in 10
> consecutive runs using the same jogl jars I generated from the commit in question

Makes sense, it's properly sync'ed via the recursive lock.

~Sven