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

On 01/22/2013 03:58 AM, Traksewt [via jogamp] wrote: We just discussed this a bit via IRC and if it is possible
to reproduce this bug w/o J3D with a minimal test case,
I like to get my hands on it using those [provided] - assuming it's our
CALayer code.

~Sven

> regards
> Kenny

The code changes I did were simply:

    private Canvas3D(Object dummyObj1,
            GraphicsConfiguration graphicsConfiguration,
            GraphicsConfiguration graphicsConfiguration2,
            boolean offScreen) {

        super(graphicsConfiguration2);

to
    private Canvas3D(Object dummyObj1,
            GraphicsConfiguration graphicsConfiguration,
            GraphicsConfiguration graphicsConfiguration2,
            boolean offScreen) {

        super(((JoglGraphicsConfiguration) graphicsConfiguration).getGLCapabilities());

and
public class Canvas3D extends Canvas implements OffscreenLayerOption {
to
public class Canvas3D extends GLCanvas {

(GLCanvas already implements OffscreenLayerOption).

I still need your fix in the JoglPipeline.java

The attached zip-file contains my contribution to the Java project "hharrison / java3d-core" hosted on github (https://github.com/hharrison/java3d-core).

The included source code is a non-exclusive contribution and comprises added or changed code in the following classes of the package 'javax.media.j3d' based on version pre5 of 2012/11/23 and JogAmp/JOGL release 2.0-rc11 :

Canvas3D, J3DGraphics2DImpl, JoglDrawable, JoglPipeline, MasterControl, NoopPipeline, Pipeline, Renderer, TextureRetained, and Texture3DRetained.

The targeted issues and features are :

1. Mac OS X 10.7+ / Oracle JRE 7+

 - JOGL's OffscreenLayerSurface approach implemented
 - Canvas3D implements javax.media.nativewindow.OffscreenLayerOption
 - new Pipeline method 'resizeOffscreenLayerSurface'
 - Renderer detects Canvas3D's size changes and performs offscreen layer resizing
 
 - Still required : fix of Mac/Oracle JRE/JOGL's x/y-positioning and z-ordering issues (see post above)

 - classes: Canvas3D, JoglPipeline, NoopPipeline, Pipeline, Renderer

2. Offscreen rendering

 - deprecated pbuffer replaced with framebuffer object
 - based on JOGL's FBO implementation GLFBODrawable and FBObject
 - pbuffer is still available if FBO isn't supported or not desired
 - double buffering and scene antialiasing support if requested and available
 - currently fixed number of samples: 4

 - classes: Canvas3D, JoglPipeline, Renderer

3. Best configuration

 - Java 3D compliant GLCapabilitiesChooser introduced : J3DCapsChooser
 - Workaround if capability chooser isn't called (Mac/JRE 7)

 - class: JoglPipeline
 
4. Texture object generation

 - internal texture object name generation replaced with OpenGL 'glGenTextures' function
 - avoids conflict with JOGL's texture object names
 - new Pipeline method 'generateTexture' implemented

 - classes: Canvas3D, J3DGraphics2DImpl, JoglPipeline, MasterControl, NoopPipeline, Pipeline, TextureRetained, Texture3DRetained  


These sources contain code and implementation approaches from the JogAmp/JOGL project, namely
 - com.jogamp.opengl.FBObject
 - javax.media.opengl.awt.GLCanvas
 - jogamp.opengl.GLDrawableHelper
 - jogamp.opengl.GLFBODrawableImpl
 
Licenses are included in the txt-file.

A new build after replacing the affected classes should run on Mac, Linux, and Windows.

August

Project-contribution_hharrison-java3d-core.zip

Can you make a pull request? Maybe it would be easier for Harvey to integrate your contributions. Thanks for the great work.

Edit.: :) it is a huge set of contributions.

Wow, this looks really interesting.  I'll likely have questions about these changes here and there, any
chance you can break it out into individual commits?  Failing that, do you have any suggestion on what order
makes the most sense for me to review/read it?


Harvey

wow wow..

This is great... Just the fix I needed. My application is back running on Mac. The scaling issue I was seeing has been fixed by your latest patches. I have downloaded a fresh jdk7u12 (and also tried jdk8) and it is all working fine.

Thanks IM!.. I can sleep easy tonight.

I read that jdk7u13 that will contain the position fix will be out Feb 19th 2013:
http://www.oracle.com/technetwork/java/java-update-release-numbers-change-1836624.html

On 01/24/2013 03:40 PM, InteractiveMesh [via jogamp] wrote:
> The attached zip-file contains my contribution to the Java project "hharrison
> / java3d-core" hosted on github (https://github.com/hharrison/java3d-core).
>

Thank you very much August!

So I guess this shows that JOGL works sufficiently (?) and
the fixes you provided are satisfactory.
Awesome.

Sure, it would be easier for Harvey to merge this using git,
however - thanks to your documentation, I guess it should be OK.

@Harvey: You can use his name + email for the git commit author field!
(sure .. you know that)

August, if above assumption is not correct, and there is a bug in JOGL,
I will be glad to hear about it, i.e. how we can fix it - of course.

Since you mention you will be at Siggraph 2013 on your webpage,
maybe you can join our BOF ? You can show your stuff there as well
and maybe talk a little bit about our 'experience'.
  https://jogamp.org/bugzilla/show_bug.cgi?id=661

At least we all can greet, meet & dine I guess.

Great!

Cheers, Sven

I agree with Sven, I would be glad to see you at Siggraph 2013, you could show some nice Java3D stuff :)

@Traksewt

Slept well? Your app runs fine because the Canvas3D fills the entire window. Am I right?


@Julien/Sven

As mentioned earlier, the most critical points are 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. Manu's Sweet Home 3D can't be run in onscreen mode due to these problems.

The event list on my webpage might be unclear, it doesn't 'announce' my participation. Thanks for your kind invitation, but it is most unlikely that I will visit Siggraph 2013.
 
 
@Harvey
 
Unfortunately, the changes have several dependencies. A runable build requires all changes to be implemented. The following order might be helpful:

At first or at last "4. Texture object generation"
 - Pipeline : new method 'generateTexture', subclasses JoglPipeline and NoopPipeline implement it
 - MasterControl : methods 'get/freeTexture2DId/Texture3DId' and the field 'textureIdCount' are removed (outcommented)
 - Canvas3D : new static method 'generateTexture' accessing the pipeline
 - J3DGraphics2DImpl and TextureRetained : call Canvas3D to generate texture object names instead of MasterControl
 - Texture3DRetained is now 'served' by its superclass TextureRetained, obsolete overriden methods are removed (outcommented)
 
Next "3. Best configuration"
 - J3DCapsChooser is added as internal class to JoglPipeline
 - JoglPipeline.getBestConfiguration is rewritten by using J3DCapsChooser and calling the added method JoglPipeline.getAWTGraphicsConfiguration
 - JoglPipeline.getGraphicsConfig is rewritten
 - JoglPipeline : removed (outcommented): internal classes CapabilitiesCapturer, IndexCapabilitiesChooser, and methods 'createAwtGraphicsConfiguration'
   
Next "2. Offscreen rendering"
 - JoglPipeline.createQueryContext supports now offscreen Canvas3D explicitly
 - JoglPipeline.createOffScreenBuffer is rewritten (requires 3.)
 - JoglPipeline.createNewContext is partly rewritten and covers offscreen and onscreen Canvas3Ds (requires 3., see also 1.)
 - JoglPipeline.readOffScreenBuffer has new code to manage FBO in addition to pbuffer
 - JoglPipeline.destroyContext covers offscreen and onscreen Canvas3Ds (see 1.)
 - JoglPipeline.destroyOffScreenBuffer is still called but currently empty
 - Canvas3D.createNewContext : 'antialiasingSet = false;' added (reason is commented)
 - Renderer.doWork : case (opArg == SWAP) don't swap a prospective double buffered AutoOffScreenCanvas3D (e.g. JCanvas3D)
 - Renderer.doWork : case 'if (reqType == MasterControl.SET_GRAPHICSCONFIG_FEATURES)' enable double buffered (auto/manual) offscreen Canvas3D
 
Next "1. Mac OS X 10.7+ / Oracle JRE 7+"
 - Canvas3D : interface OffscreenLayerOption implemented
 - JoglDrawable : NativeWindow support added
 - JoglDrawable : method 'hasFBObjectSizeChanged' added, called from Renderer
 - JoglPipeline : internal class QueryCanvas adapted
 - JoglPipeline.createQueryContext adapted
 - JoglPipeline.createNewContext is partly rewritten and covers offscreen and onscreen Canvas3Ds (requires 3., see also 2.)
 - Pipeline : new method 'resizeOffscreenLayerSurface', subclasses JoglPipeline and NoopPipeline implement it
 - JoglPipeline.resizeOffscreenLayerSurface added
 - Renderer.doWork : Canvas3D/FBObject size check, calling JoglPipeline.resizeOffscreenLayerSurface
 - JoglPipeline.destroyContext covers offscreen and onscreen Canvas3Ds (see 2.)

August

InteractiveMesh wrote

@Julien/Sven

As mentioned earlier, the most critical points are 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.

I can't help on this trouble without a Mac.

InteractiveMesh wrote

Java 3D's Canvas3D is affected accordingly. Manu's Sweet Home 3D can't be run in onscreen mode due to these problems.

Could we use NewtCanvasAWT in Java3D? Would it help a bit?

InteractiveMesh wrote

The event list on my webpage might be unclear, it doesn't 'announce' my participation. Thanks for your kind invitation, but it is most unlikely that I will visit Siggraph 2013.

Ok. Let us know if you wish we show some of your stuff.

"Could we use NewtCanvasAWT in Java3D? Would it help a bit?"

I don't think so. In my provided samples GLCanvas and NewtCanvasAWT behave identically: they are rendered always in the front and are positioned in the lower left corner at start time.

All JOGL implementations of AWT canvases GLCanvas, NewtCanvasAWT, and Canvas3D rely on com.jogamp.nativewindow.awt.JAWTWindow. Is this one of the culprits?

August

I believe your x,y issue and my x,y issue were different. Your issue sounds like x,y, scaling/positioning isn't working at all and is returning 0, hence it being in the bottom left corner.

My issue was scaling was overscaling, so if you resize the window 100 px larger in the x, then the canvas would resize the graphic ~200px, making the image drift off the right of the screen. Likewise same issue for y scaling pushing the image past the top of the window. By quickly scanning your changes, I'm guessing that 'JoglPipeline.resizeOffscreenLayerSurface' was the fix I needed.

My app has multiple Canvas3D's laid out in multiple JSplitPanes (though some of them are just using 2D rendering):
http://odonoghuelab.org/tmp/aquariatest.png

I just tested out the applet too and it works.

This is a 11 year old app that I am getting working again with improvements. I believe my workmate Christian met Sven and mentioned about our project at last year's Siggraph 2012.

On 01/25/2013 03:05 PM, InteractiveMesh [via jogamp] wrote:
> /"Could we use NewtCanvasAWT in Java3D? Would it help a bit?"
> /
> I don't think so. In my provided samples GLCanvas and NewtCanvasAWT behave
> identically: they are rendered always in the front and are positioned in the
> lower left corner at start time.
>
> All JOGL implementations of AWT canvases GLCanvas, NewtCanvasAWT, and Canvas3D
> rely on com.jogamp.nativewindow.awt.JAWTWindow. Is this one of the culprits?

Yes, of course - the CLayer mechanism is bound to it's information,
again - we assume that the given root CALayer is on it's right position
and we position our sub CALayer (which we attach to the root CALayer) at 0/0.

~Sven

>
> August

FYI, I've pushed August's changes out to github on an al-contrib branch in case anyone wants to play
with them before I have a chance to finish reviewing them.

In the usual place:
https://github.com/hharrison/java3d-core/

Harvey

I tried Oracle's JDK7 u13 that just came out and it still has the position bug. While the OpenJDK u12 works!

jdk7u12
http://jdk7.java.net/download.html this one works

jdk7u13
http://java.com/en/download/mac_download.jsp this one doesn't work…

I would have thought the fixes would have been in sync. oh well.

BTW, I am seeing another position bug when resizing the JSplitPane, which may be related to InteractiveMesh's position issue. When I resize the JSplitPane, the layout gets corrupted. Then if I resize the whole window slightly, it will correct itself.

On 02/05/2013 12:01 PM, Traksewt [via jogamp] wrote: We do have a JSplitPlane unit test in JOGL .. and I also have seen some
light/heavy weight issues there regarding size of GLCanvas.

However, our unit test does not test x/y positions other than 0/0 AFAIK.

Maybe you can create a new unit test based on this one.

+++

Documenting Bug 642 (related to Bug 586)

com.jogamp.opengl.test.junit.jogl.awt.TestBug642JSplitPaneMixHwLw01AWT

+++

~Sven

Due to several critical patch updates the numbering changed:

 - JDK 7u13 = JDK 7u11 + security fixes

 - JDK 7u14 ea = JDK 7u12 ea  

Haven't found any JDK 7u14 builds so far.

August

InteractiveMesh wrote:
>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

Does anyone know when this fix gets into the Oracle JRE 7 stream? The latest Oracle java u21 still has this position bug. We are releasing our software soon, and we have to write a note to install OpenJDK u12 to get it working on Mac, which is less than ideal.

Sounds like this bug was fixed last year, I wasn't expecting it to take so long to get into the main stream. The defect says: Fixed Versions: 7u40, which is a worry as we are currently on 7u21. I'm wondering if that (7u40) is a future placeholder that means it isn't in plan and is unlikely to come in soon. Anyone know how to apply pressure to get this in earlier? It would be a shame if Java3D on MacOS will only work on Java8 when it comes out.

k

Traksewt wrote

InteractiveMesh wrote:
>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

Does anyone know when this fix gets into the Oracle JRE 7 stream? The latest Oracle java u21 still has this position bug. We are releasing our software soon, and we have to write a note to install OpenJDK u12 to get it working on Mac, which is less than ideal.

Sounds like this bug was fixed last year, I wasn't expecting it to take so long to get into the main stream. The defect says: Fixed Versions: 7u40, which is a worry as we are currently on 7u21. I'm wondering if that (7u40) is a future placeholder that means it isn't in plan and is unlikely to come in soon. Anyone know how to apply pressure to get this in earlier? It would be a shame if Java3D on MacOS will only work on Java8 when it comes out.

k

The next major 7 non-security feature & bug-fix release 7u40 is scheduled for general release by Oracle at late August 2013.
You have to check the Oracle's JDK 7 Update Releases page for further/updated information.
http://openjdk.java.net/projects/jdk7u/
http://openjdk.java.net/projects/jdk7u/releases/7u40.html

Oracle invented a new JDK version number scheme in hope to avoid renumbering releases in the future.
http://www.oracle.com/technetwork/java/javase/overview/jdk-version-number-scheme-1918258.html

Xerxes Rånby wrote

Traksewt wrote

InteractiveMesh wrote:
>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

Does anyone know when this fix gets into the Oracle JRE 7 stream? The latest Oracle java u21 still has this position bug. We are releasing our software soon, and we have to write a note to install OpenJDK u12 to get it working on Mac, which is less than ideal.

Sounds like this bug was fixed last year, I wasn't expecting it to take so long to get into the main stream. The defect says: Fixed Versions: 7u40, which is a worry as we are currently on 7u21. I'm wondering if that (7u40) is a future placeholder that means it isn't in plan and is unlikely to come in soon. Anyone know how to apply pressure to get this in earlier? It would be a shame if Java3D on MacOS will only work on Java8 when it comes out.

k

The next major 7 non-security feature & bug-fix release 7u40 is scheduled for general release by Oracle at late August 2013.
You have to check the Oracle's JDK 7 Update Releases page for further/updated information.
http://openjdk.java.net/projects/jdk7u/
http://openjdk.java.net/projects/jdk7u/releases/7u40.html

Before general release, GA, Oracle only offer 7u40 JDK 7 Update 40 Early Access Release builds from java.net
https://jdk7.java.net/download.html
These builds includes the fix but are releases under a non-distributable "draconian" Pre-Release Software Evaluation Agreement license.

I recommend you to build your own version of OpenJDK 7u40 using the GPL licensed sourcecode and ship it with your project.
Gomez Henri: have prepared some build scripts that may help build OpenJDK for MacOSX https://github.com/hgomez/obuildfactory