Issue with Java 3D under OpenJDK 7 / Mac OS X

Hi,

I'm the developer of Sweet Home 3D, an open source Swing / Java3D interior design application, and I'm very happy to see the revival of Java 3D on top of the latest version of JOGL, before all because without it, we were close to a sad end to run Java 3D with the upcoming OpenJDK under Mac OS X.

As the bottom part of the following image shows, my first tests with the latest build were successful with Java 6 under Mac OS X.



Miserably, when I switch to OpenJDK 7, the program can't run and I get the following error in the console:

javax.media.opengl.GLException: drawable has invalid handle: MacOSXOnscreenCGLDrawable[Realized true,
        Factory   jogamp.opengl.macosx.cgl.awt.MacOSXAWTCGLDrawableFactory@6eebe07e,
        handle    0x0,
        Window    JAWT-Window[windowHandle 0x7ff63d7b7f60, surfaceHandle 0x0, bounds [ 0 / 0  765 x 526 ], insets [ l 0, r 0 - t 0, b 0 - 0x0], shallUseOffscreenLayer false, isOffscreenLayerSurface true, pos 0/0, size 765x526, visible true, lockedExt false,
        config AWTGraphicsConfiguration[AWTGraphicsScreen[AWTGraphicsDevice[type AWT, connection Display 69678464, unitID 0, awtDevice sun.awt.CGraphicsDevice@ef28a30, handle 0x0], idx 0],
        chosen    GLCaps[offscr, rgba 0x5/5/5/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/0, dbl, mono  , hw, GLProfile[GL2/GL2.hw], pixmap],
        requested GLCaps[on-scr, rgba 0x5/5/5/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/0, dbl, mono  , hw, GLProfile[GL2/GL2.hw]],
        CGLGraphicsConfig[dev=69678464,pixfmt=0],
        encapsulated MacOSXCGLGraphicsConfiguration[DefaultGraphicsScreen[MacOSXGraphicsDevice[type MacOSX, connection decon, unitID 0, handle 0x0], idx 0],
        chosen    GLCaps[offscr, rgba 0x5/5/5/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/0, dbl, mono  , hw, GLProfile[GL2/GL2.hw], pixmap],
        requested GLCaps[on-scr, rgba 0x5/5/5/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/0, dbl, mono  , hw, GLProfile[GL2/GL2.hw]]]],
        awtComponent com.eteks.sweethome3d.j3d.Component3DManager$1[canvas2,0,0,765x526],
        surfaceLock <708a932f, 19c52c62>[count 1, qsz 0, owner <J3D-Renderer-1>]]]
        at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:422)
        at javax.media.j3d.JoglPipeline.createNewContext(JoglPipeline.java:6238)
        at javax.media.j3d.Canvas3D.createNewContext(Canvas3D.java:4815)
        at javax.media.j3d.Canvas3D.createNewContext(Canvas3D.java:2439)
        at javax.media.j3d.Renderer.doWork(Renderer.java:907)
        at javax.media.j3d.J3dThread.run(J3dThread.java:275)
Error in Java 3D : 3 Renderer: Error creating Canvas3D graphics context


Before going further, I prefer to ask for your opinion. Maybe it's a simple adjustment required on my side.
Thanks for your help

Hi

If it goes on, I will regret not having implemented NEWT support in Java3D when I ported it to JOGL 2.0. This is probably a bug coming from JOGL or AWT implementation of OpenJDK under Mac OS X. Please can you try to reproduce your bug with examples using plain JOGL without Java3D?

Thank you for your feedback.
This is going to be very hard for me to reproduce because my knowledge in OpenGL and JOGL is small.
Don't you have any test/example in mind that I could run to check this issue under OpenJDK 7?

On 06/20/2012 06:31 PM, Manu [via jogamp] wrote: Nice software it seems - kudos.

Well, I put this on my OSX stash of work
and will see whether I can fix it when working at it.

Looks like it's on my side of the project .. hmm.

+++

@Julien: Do you 'cache' (store) GLDrawable/GLContext data in J3D ?
This could be a source of error, since the offscreen path (OpenJDK7, OSX,
CALayer only) may destroy and recreate the GLDrawable when resizing.
The latter goes w/ all offscreen path, ofc.

If so, please hook to 'dispose()' and 'init()' of the listener
and act accordingly, i.e. expect the recreation.

+++

@Manu: Please state the exact information of
- your machine (-> Wiki/FAQ/Bugreport)
- the JOGL, J3D and your software package

it will become very useful when I triage the situation.

+++

~Sven

Can you expand a little bit more on what the lifetime rules of the GLDrawable are that you think Java3d
might be violating...I can have a look around and see if it is caching a GLDrawble anywhere....I have my
suspicions it may be somewhere.

Harvey, Sven is right, we cache GLDrawable instances.

On 06/21/2012 05:24 AM, hharrison [via jogamp] wrote:
> Can you expand a little bit more on what the lifetime rules of the GLDrawable
> are that you think Java3d
> might be violating...I can have a look around and see if it is caching a
> GLDrawble anywhere....I have my
> suspicions it may be somewhere.

It's the lifecycle rules from NativeSurface, i.e.
native handles stay valid while it's locked.

You can never assume _same_ handles for the next locking period.

GLDrawable/GLContext lock it's NativeSurface at makeCurrent(..)
and release it w/ release() - 1 frame rendering.

Further more, if GLCanvas is offscreen, it may destroy and recreate:
  - jawtWindow
  - drawable
  - context
in case of resizing it. Sure this is required to match the offscreen
framebuffer w/ the window size.

During this recreation, dispose() and init() of the GLEventListeners
are being called and it's required to release/create all GLContext
resources.
The only way to avoid recreating these resources are by using a
primary GLContext which holds all data (textures, VBOs)
which then gets shared w/ the GLCanvas's GLContext.

We cannot add this functionality in GLCanvas in an automatic manner
due to the low level nature of our binding - and hence the transparent
exposed GLContext to the user.

Hence the Java3D usage of GLCanvas should take care of this recreation.
Sure - I don't know whether this is the culprit here,
but the exception (invalid drawable/window handle) points in that direction.

We know that the AWT GLCanvas is always offscreen on:
  - OSX >= 10.5.8 + Applets
  - OSX >= 10.5.8 + OpenJDK7
In both cases the now pbuffer (and future FBO) will be
composited by Apple's CALayer .. (performance?).

As Julien pointed out, using a direct NEWT window (not NewtCanvasAWT)
would allow you to use an onscreen window on all platforms.

However, since it's probably desired to also support Java3D w/ Applets
on OSX - the offscreen path might need to be handled.

I hope the above elaboration helps ..

@Harry: I guess it's time to drop your branch to our Jenkins build system.
        Please email me about the details,
        so I can start doing so this weekend.
        - Git repos
        - Build order
        - Required build magic ?

~Sven

Sven, my tests were made under an iMac 2010 i7 with an ATI Radeon HD 5750, running Mac OS X 10.7.3 and OpenJDK-OSX-1.7-universal-u-jdk-jdk7u6-b14-20120615.dmg build.
Thank you all for taking care of this issue.

Emmanuel, would it be difficult for you to switch to NEWT on the long term?

gouessej wrote

would it be difficult for you to switch to NEWT on the long term?

Sorry I don't know NEWT and I'm not the kind of person ready to jump on a new API each time a developer creates one.
Until now, I'm quite happy with Java3D, and if I had to give it up, I would probably jump to OpenGL or a thin API over OpenGL like JOGL.
Can you give me more information about NEWT and why do you think about it?

On 06/21/2012 11:15 AM, Manu [via jogamp] wrote:
>     gouessej wrote
>     would it be difficult for you to switch to NEWT on the long term?
>
> Sorry I don't know NEWT and I'm not the kind of person ready to jump on a new
> API each time a developer creates one.

NEWT is already quite mature, initiated around 2008.

> Until now, I'm quite happy with Java3D, and if I had to give it up, I'll
> probably jump to OpenGL or a thin API over OpenGL like JOGL.

Well, I guess the question was weather you use Java3D or JOGL directly,
but weather you would be OK to use a NEWT Window instead of an AWT
Canvas/GLCanvas _with_ Java3D.

This would require you to rewrite your event input handlers,
which is not a big task - since we use _same_ names and semantics.

> Can you give me more information about NEWT and why do you think about it?

https://jogamp.org/jogl/doc/NEWT-Overview.html

However, as mentioned previously, even if using NEWT,
in case the NEWT Window is attached to AWT (NewtCanvasAWT, Applets)
the offscreen issue remains - and needs to be solved.
So maybe switching to NEWT would not satisfy in this regard.

One reason for switching to NEWT is to benefit from
better input responsive, i.e. NEWT won't lag your user input (mouse/key/..).
This is described in the URL above. A few projects already using NEWT
in this regard.

~Sven

The big probelm here is that the fundamental building block of Java3d is the Canvas3d, which inherits from java.awt.Canvas,
this is the big AWT (or swing, depending on how you look at it) dependency that is inherent in using Java3d, I don't think NEWT
is really on option without separating this somehow.   Mind you, if you assume only the JOGL2 backend, you could internally
use the GLDrawable everywhere and break the dependency...but that's not a trivial amount of work.

Harvey

On 06/22/2012 12:20 AM, hharrison [via jogamp] wrote:
> The big probelm here is that the fundamental building block of Java3d is the
> Canvas3d, which inherits from java.awt.Canvas,
> this is the big AWT (or swing, depending on how you look at it) dependency
> that is inherent in using Java3d, I don't think NEWT
> is really on option without separating this somehow.   Mind you, if you assume
> only the JOGL2 backend, you could internally
> use the GLDrawable everywhere and break the dependency...but that's not a
> trivial amount of work.

As I said, using NEWT would not solve the Applet problem,
but you could benefit from it for other great reasons:
  performance, mobile, ..
However, it is off-thread regarding this bug.

Does my writing
<http://forum.jogamp.org/Issue-with-Java-3D-under-OpenJDK-7-Mac-OS-X-tp4025259p4025271.html>
help ?

BTW .. sorry, Harvey - not Harry. My fault:

> @Harry: I guess it's time to drop your branch to our Jenkins build system.
>         Please email me about the details,
>         so I can start doing so this weekend.
>         - Git repos
>         - Build order
>         - Required build magic ?

>
> Harvey
>

~Sven

I'm still absorbing your other comment, it does help...but will probably lead to more questions :-)

WRT NEWT, unless I'm missing something obvious, Java3d has a direct dependency on AWT (for now)
in that the drawing done by Java3d relies directly on an AWT object (java.awt.Canvas) and the AWT
threading model.  This is the part that would need to change to allow the drawing to work with an
actual drawble, or allow a different threading model.

I do plan to look into this, at least to try and make the existing model not explode on MacOSX, and
possibly try and produce an alternate model to Java3d for drawing to a non-AWT object.

Any news about this issue?

Emmanuel, I don't even succeed in running your program with OpenJDK 1.7 under GNU Linux, even with my fixes.

If you get a "java.awt.IllegalComponentStateException: The frame is decorated" exception, please comment the line macosxApplication.setDefaultMenuBar(defaultMenuBar); in MacOSXConfiguration.java

No it was something completely different. Have you succeeded in running it with JOGL 2 RC 10?

gouessej wrote

Have you succeeded in running it with JOGL 2 RC 10?

From the recent messages you exchanged with Harvey, Java 3D can't run with RC10 yet. Hope it will work better after that...

I ran Java3D 1.6.0 with JOGL 2.0 RC10 during Siggraph 2012, I fixed the few incompatibilities but I forgot to copy the source code onto my disk, that's why I suggested him to reimplement my fixes :s

I had to run your software with JOGL 1.1.1a because the creation of your 3D canvas failed with JOGL 2.0 RC10 despite my fixes.