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

What kind of problems could I expect?
Isn't this update supposed to fix problems?

Manu wrote

What kind of problems could I expect?
Isn't this update supposed to fix problems?

Some problems are fixed by the update of JOGL but some others come from at least one design flaw of Java 3D.

On 10/18/2012 11:00 AM, elotter [via jogamp] wrote:
> How's the progress with RC11 and binary downloadable jars (auto builds?)

RC11 will be out before Monday, currently fixing a few more issues/features
in the fixed function emulation,
plus the OSX GL3 core ctx must work w/ CALayer (a missing feature / bug).

~Sven

I tried today with JOGL b835 autobuilds, and it gave me some similar errors under Windows and Linux (but different from the one I previously reported under Mac OS X):

- Under Windows, the VM crash log was:

Stack: [0x07870000,0x078c0000],  sp=0x078bf900,  free space=318k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [prl_gldd.dll+0xcc12]
C  [prl_gldd.dll+0x13f4f]
C  [extension2378866328423935713.dll+0x17a56]  Java_jogamp_opengl_gl4_GL4bcImpl_dispatch_1glLightModeli1__IIJ+0x16
j  jogamp.opengl.gl4.GL4bcImpl.dispatch_glLightModeli1(IIJ)V+0
j  jogamp.opengl.gl4.GL4bcImpl.glLightModeli(II)V+35
j  javax.media.j3d.JoglPipeline.updateSeparateSpecularColorEnable(Ljavax/media/j3d/Context;Z)V+25
j  javax.media.j3d.Canvas3D.updateSeparateSpecularColorEnable(Ljavax/media/j3d/Context;Z)V+5
j  javax.media.j3d.Canvas3D.enableSeparateSpecularColor()V+21
j  javax.media.j3d.Renderer.doWork(J)V+3832
j  javax.media.j3d.J3dThread.run()V+19
v  ~StubRoutines::call_stub
V  [jvm.dll+0xfb05b]
V  [jvm.dll+0x18c901]
V  [jvm.dll+0xfb201]
V  [jvm.dll+0xfb25b]
V  [jvm.dll+0xb5619]
V  [jvm.dll+0x119334]
V  [jvm.dll+0x14158c]
C  [msvcr71.dll+0x9565]  endthreadex+0xa0
C  [kernel32.dll+0x133aa]  BaseThreadInitThunk+0x12
C  [ntdll.dll+0x39ef2]  RtlInitializeExceptionChain+0x63
C  [ntdll.dll+0x39ec5]  RtlInitializeExceptionChain+0x36

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  jogamp.opengl.gl4.GL4bcImpl.dispatch_glLightModeli1(IIJ)V+0
j  jogamp.opengl.gl4.GL4bcImpl.glLightModeli(II)V+35
j  javax.media.j3d.JoglPipeline.updateSeparateSpecularColorEnable(Ljavax/media/j3d/Context;Z)V+25
j  javax.media.j3d.Canvas3D.updateSeparateSpecularColorEnable(Ljavax/media/j3d/Context;Z)V+5
j  javax.media.j3d.Canvas3D.enableSeparateSpecularColor()V+21
j  javax.media.j3d.Renderer.doWork(J)V+3832
j  javax.media.j3d.J3dThread.run()V+19
v  ~StubRoutines::call_stub

- Under Linux, the VM crash log was:

 Stack: [0x00007f59cc05b000,0x00007f59cc15c000],  sp=0x00007f59cc15a230,  free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libGL.so.1+0x45ab4]  glLightModeli+0x44

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  jogamp.opengl.gl4.GL4bcImpl.dispatch_glLightModeli1(IIJ)V+0
j  jogamp.opengl.gl4.GL4bcImpl.glLightModeli(II)V+35
j  javax.media.j3d.JoglPipeline.updateSeparateSpecularColorEnable(Ljavax/media/j3d/Context;Z)V+25
j  javax.media.j3d.Canvas3D.updateSeparateSpecularColorEnable(Ljavax/media/j3d/Context;Z)V+5
j  javax.media.j3d.Canvas3D.enableSeparateSpecularColor()V+21
j  javax.media.j3d.Renderer.doWork(J)V+3832
j  javax.media.j3d.J3dThread.run()V+19
v  ~StubRoutines::call_stub

Hope this can help...

Some drivers for ATI HD graphics cards have a bug in light handling, I already saw something similar several days ago. There was something to modify in the shininess.

JogAmp RC11 is now released:
http://forum.jogamp.org/Release-v2-0-rc11-td4026703.html

Please re-test!

Since Harvey didn't post any Java 3D update since his message on Oct 04, 2012, I didn't expect it would work, but nevertheless, I tested JogAmp rc11 last week with this Jar Executable file.
Under Java 1.7 and Mac OS X, I get a very similar error:

javax.media.opengl.GLException: BackingLayerHost w/ unknown handle (!FBO, !PBuffer): MacOSXOnscreenCGLDrawable[Realized true,
	Factory   jogamp.opengl.macosx.cgl.awt.MacOSXAWTCGLDrawableFactory@69c13fc4,
	Handle    0x7fb00769aa10,
	Surface   JAWT-Window[windowHandle 0x7fb00769a280, surfaceHandle 0x7fb00769aa10, 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@69950b4, handle 0x0], idx 0],
	chosen    GLCaps[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], offscr[auto-cfg]],
	requested GLCaps[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], on-scr[.]],
	CGLGraphicsConfig[dev=69678464,pixfmt=0],
	encapsulated MacOSXCGLGraphicsConfiguration[DefaultGraphicsScreen[MacOSXGraphicsDevice[type .macosx, connection decon, unitID 0, handle 0x0, NullToolkitLock[]], idx 0],
	chosen    GLCaps[rgba 0x8/8/8/8, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/0, dbl, mono  , hw, GLProfile[GL2/GL2.hw], on-scr[.]],
	requested GLCaps[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], on-scr[.]]]],
	awtComponent com.eteks.sweethome3d.j3d.Component3DManager$1[canvas2,0,0,765x526],
	surfaceLock <558f6df5, 3b7c1bb5>[count 1, qsz 0, owner <J3D-Renderer-1>]]]
	at jogamp.opengl.macosx.cgl.MacOSXCGLContext$NSOpenGLImpl.contextRealized(MacOSXCGLContext.java:647)
	at jogamp.opengl.macosx.cgl.MacOSXCGLContext.contextRealized(MacOSXCGLContext.java:333)
	at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:536)
	at javax.media.j3d.JoglPipeline.createNewContext(JoglPipeline.java:6198)
	at javax.media.j3d.Canvas3D.createNewContext(Canvas3D.java:4773)
	at javax.media.j3d.Canvas3D.createNewContext(Canvas3D.java:2407)
	at javax.media.j3d.Renderer.doWork(Renderer.java:893)
	at javax.media.j3d.J3dThread.run(J3dThread.java:270)
J3dI18N: Error looking up: Renderer7
Error in Java 3D : 3 Renderer7Nov 10 18:13:16 eTeks-iMac.local java[16200] <Error>: CGContextGetCTM: invalid context 0x0
Nov 10 18:13:16 eTeks-iMac.local java[16200] <Error>: CGContextSetBaseCTM: invalid context 0x0

Under Windows, it's the same error as the one I reported on Oct 23, 2012. If the error comes from the driver, couldn't JOGL or Java 3D be updated to avoid the crash? Note that it works with Java 3D 1.5.2.

After Harvey suggested to use only offscreen canvases, I could make Sweet Home 3D run under Java 7 / Mac OS X.
As two users recently reported they had problems to reinstall Java 6 under Mac OS X 10.7 or 10.8 to run Sweet Home 3D (see here and here), I prereleased a version of Sweet Home 3D bundled with Java 7 even if it's still not perfect. If interested, please read more here.

A Canvas3D with implemented interface 'OffscreenLayerOption' and adapted context creation according to the design of AWT GLCanvas and as asked for by Sven above doesn't throw the GLException 'BackingLayerHost w/ unknown handle' anymore. Sweet Home 3D starts - unfortunately - with a not correctly positioned Canvas3D within a JSplitPane.

Emmanuel, thanks a lot for testing and providing pictures of this test case.

I transferred my changes into Harvey's Canvas3D and JoglPipeline classes and in agreement with him I make them available here. The file also includes the pictures : PastedGraphic-3.png/test result, PastedGraphic-4.png/default.

Changes in short:

Canvas3D/OffscreenLayerOption

  // Accessed in JoglPipeline.createNewContext    
  JAWTWindow jawtWindow = null;
  boolean shallUseOffscreenLayer = false;

  public void setShallUseOffscreenLayer(boolean v) {
    shallUseOffscreenLayer = v;
  }

  public final boolean getShallUseOffscreenLayer() {
    return shallUseOffscreenLayer;
  }

  public final boolean isOffscreenLayerSurfaceEnabled() {
    final JAWTWindow jawtwindow = jawtWindow;
    if (jawtwindow != null) {
      return jawtwindow.isOffscreenLayerSurfaceEnabled();
    }
    return false;
  }    

JoglPipeline.createNewContext

  cv.jawtWindow = (JAWTWindow)NativeWindowFactory.getNativeWindow(cv, awtGraphicsConfiguration);
  cv.jawtWindow.setShallUseOffscreenLayer(cv.shallUseOffscreenLayer);    
  cv.jawtWindow.lockSurface();
  try {
    draw = GLDrawableFactory.getFactory(profile).createGLDrawable(cv.jawtWindow)
    context = draw.createContext(context(shareCtx));
  }
  finally {
    cv.jawtWindow.unlockSurface();
  }

Emmanuel, is the Canvas3D positioned correctly when displayed in the separated window?

August

mac-jre-issue-testcase.zip

Thanks August,

I was having a crashing applet too, and now I have the applet running thanks to your fix. The applet launches a separate popup window in the top left. Ideally it would be embedded, but at least it isn't crashing now.

Kenny

On 12/02/2012 05:01 PM, InteractiveMesh [via jogamp] wrote: Excellent. Thank you for helping w/ our common Java3D continuation.

I assume Harvey will merge your effort, if you don't have send him a
git pull request already.

This process is ofc much better for us than picking stuff our of your
other Java3D branch we once talked about. Better as in 'saves time'
and 'easier to validate the license'.

Kudos.

~Sven

@Traksewt,

is the scene rendered correctly when the separate popup window is resized? I'm doubtful.
   
@Sven,

the Canvas3D is not only positioned inaccurately but also the scene's content is rendered in weird size (Canvas3D's size is ok). The latter seems to result from the fact that the FBO/pbuffer will currently not be resized/renewed as in GLCanvas.reshape -> GLDrawableHelper.resizeOffscreenDrawable/recreateGLDrawable. This has to be implemented next. But, positioning (and sizing) the Canvas3D (a java.awt.Component) within the JFrame is handled by the JRE. Is JOGL's specific Mac implementation (CALayer) involved as well?

August

InteractiveMesh wrote

Emmanuel, is the Canvas3D positioned correctly when displayed in the separated window?

I can't test that feature. When I try to display the Canvas3D instance in a separated window, the program hangs. As it happens too when I try to quit the application with your implementation, I guess it comes from the cleanup method of SimpleUniverse class called when the ancestor of Canvas3D is removed.

@August, you are correct. My trivial triangle example slides offscreen when I try to resize the window.

Regarding positioning of the Canvas3D I found following bug. I guess Canvas3D and JOGL's GLCanvas might be affected. The fix will be available in 7u12.

JDK 7 Bug 2229714 : [macosx] JAWT native CALayer not positioned over Canvas http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2229714
JDK 8 Bug 7172187 : [macosx] JAWT native CALayer not positioned over Canvas http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172187

JDK 7u12 schedules http://openjdk.java.net/projects/jdk7u/releases/7u12.html
 - Mid Jan 2013      All planned bug fixes completed
 - End of Apr 2013  GA
 
Further Canvas3D related issues (e.g. scene resizing) are in work.

August

On 12/17/2012 11:15 AM, InteractiveMesh [via jogamp] wrote: Excellent news.

I encountered difficulties w/ it when testing on OSX w/ our GLCanvas
or NewtCanvasAWT - however, I was able to fix some native CALayer positions
in the native code.

AFAIK it works quite OK in this use cases, hence the question why?
Maybe our little tests are not sophisticated enough to reproduce the bug
and need more 'AWT' layout?

~Sven

> August

Has anyone here tested the Mac JDK fix?

I built the JDK according to :
https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port

by getting the latest JDK7u.

By checking the code, I saw it has the fixes listed here:
http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/73a2bcfba54a

I tried it out and it still gives the a scaling issue still when resizing the canvas.

The scaling issue is not as bad as before, but the Y axis is inverted. ie when you resize the window down the canvas disappears to the top of the window.

The X axis is over-scaling. So when you expand the window to the right, the canvas disappears to the right.

Sorry for remaining silent for such a long time.

I struggled with issues caused by textures. JOGL's FBObject is using a texture as offscreen render target which name/ID is generated by OpenGL, but Java 3D creates its own texture IDs. The ID '1' is used by both for different textures. This results in not really funny rendering. So, I'm going to adapt the texture ID generation in Java 3D.

A Java 3D compliant capability chooser is now implemented. But GraphicsConfigTemplate3D still doesn't allow to set the number of samples for scene antialiasing and JCanvas3D still disables double buffering.

It seems that the resizing issue is fixed.

Offscreen rendering is now based on FBO with MSAA support. Pbuffer (deprecated on Mac) will be used if FBO is not supported (unlikely on 10.7+ with dedicated graphics card). Mac OS X doesn't support MSAA for pbuffers on AMD cards without a workaround.

Most critical: Mac/Oracle JRE/JOGL's x/y-positioning and z-ordering issues, see http://forum.jogamp.org/Mac-OS-X-10-7-Oracle-JRE-7-Swing-integration-issues-td4027780.html . Java 3D's Canvas3D is affected accordingly. A workaround for the x/y-positioning might be to change the size of the Canvas3D or its parent after the Canvas3D is added and visible.

August  

Thank you for investigating and sharing your findings. Can't we use FBObject in Java3D?

@IM, did you successfully get past the x,y scaling when resizing issue? I have the JDK7u and JDK8 with the fix you mentioned above and the scaling when resizing issue is still there for me.

I made Canvas3D inherit from GLCanvas (instead of Canvas) and that got rid of the crashing problem without needing your 1/2 of your fix ( the part in Canvas3D/OffscreenLayerOption) as it is now in the superclass.

However, the Canvas3D is still using its own paint method at the moment.

Regarding the scaling when resizing, it looks like it is overscaling everything from the origin at the bottom left. Maybe it is scaling it twice? Anyone have any ideas where to look?

regards
Kenny