Request for testing on OSX 1.6.0-pre6 released

I've merged and pushed out August Lammersdorf's changes to allow Java7 and OSX support
for Java3D....please go forth and test.  github has recently removed the file-hosting support, so
get the prebuilt jars here:

Emmanual, I also made the boolean property setting stuff less chatty, so you shouldn't see the spew to
stderr anymore when setting properties.

http://jogamp.org/deployment/java3d/1.6.0-pre6/

Happy testing!

Harvey

Hi

Ok I'll have to update my article. Where can I find vecmath.jar? Can you put it into the same directory?

Thanks Harvey.

I tested Java 3D 1.6.0-pre6 successfully under Mac OS X with Apple's Java 6 and Oracle's Java Plug-in 7.
Strangely, Sweet Home 3D application launched with java 1.7.0_13 hangs at program startup on my computer with no information in the console (but it was the case with 1.6.0-pre5 too). Anyway, as I discovered a very bad bug in Java 7 under Mac OS X that prevents the use of accentuated letters in file paths (when I run new javax.swing.JFileChooser().showOpenDialog(null); in an application, all files with accentuated letters are missing!), I won't support Java 7 and Java 3D 1.6.0 in coming Sweet Home 3D 4.0 applications, since Apple's Java 6 can still work in .app bundles until further notice. But I will support Java 7 and Java 3D 1.6.0 in Sweet Home 3D 4.0 applets because the accentuated letters in file paths bug doesn't happen with applets, and reconfiguring the Mac OS X 10.7 or 10.8 to use Apple's Java 6 plug-in is not so easy.
As I'm still obliged to use JCanvas3D instead of simple Canvas3D with Java 3D 1.6.0 because of a remaining bug in Java 7, could you try to support antialiasing in JCanvas3D too? As antialiasing works in offscreen images, it shouldn't be too difficult, right?

Thanks for testing.  I'll assume the booleanproperty spew is gone for you now as well?

So, what are the remaining problems (with Java3d 1.6) that would keep you from using it for all your deployments?

WRT to JCanvas3D, it shouldn't (fingers crossed) be too hard to do at this point, likely it is just filtering the
antialiasing flag out explicitly becasue offsceen canvases didn't used to support it, just a matter of finding where :-)

Harvey

Julien,

It's there now, cheers.

http://jogamp.org/deployment/java3d/1.6.0-pre6/vecmath.jar

Harvey

hharrison wrote

I'll assume the booleanproperty spew is gone for you now as well?

Yes

hharrison wrote

So, what are the remaining problems (with Java3d 1.6) that would keep you from using it for all your deployments?

Many reasons in fact:
- Unless I'm obliged to, I prefer to wait for final releases and not put in production prerelease and release candidate versions.
- Java3D 1.6 / JOGL 2 still crashes under Windows run with Parallels Desktop. Maybe it's a driver issue in Parallels Desktop or the problem was already there with Java3D 1.5.2 run with JOGL 1.1, but as it's my standard Windows PC, I can't release something I can't regularly test myself successfully. And who knows how many users with old or not updated drivers would have similar issues? As Java 3D 1.6 relies only on OpenGL, I even won't be able to tell them to try with DirectX implementation anymore.
- Under Mac OS X, using only Java3D 1.6 would oblige me to drop support for Macs running with a PowerPC and/or Mac OS X 10.4 because only Java 5 exists on these computers and JOGL 2 doesn't support Java 5.
- Finally, as said in my previous message, I prefer to rely on Apple's Java 6 than on Oracle's Java 7 which is still too buggy to my taste. As Apple's Java 6 supports Java3D 1.5.2, I prefer to wait for the final release of Java3D 1.6 and JOGL 2 to use them, even if its support of antialiasing in offscreen images is a nice add-on. But don't worry, I'll use it in a future update of Sweet Home 3D. At this time, it will be for the applet run with Java 7 plug-in.

Sounds like some good reasons, thanks for sharing.

This definitely sounds like something that time will sort out for us.

Thanks for testing, I'll put out a new build of j3dutils tonight with the JCanvas3D aliasing fix.

Harvey

I have updated my tutorial, thanks.

Thanks, the previous version of Java3D 1.6 did not work correctly for my Mac OS X test system (JDK7u13) with no 3D being rendered at all, but it seems that pre-6 now allows the 3D view to work! However, and this could potentially be due to my application being built on the NetBeans Platform, I'm observing a strange offset in the rendering position of the canvas, see the attached screenshot: The size seems correct, and should fit in the TopComponent (NB API) of which you can see the outline, but it ends up offset from it, blocking other UI elements. Any ideas?

Thanks for testing Ernest,

The offset problem is known about, and is likely a problem in the AWT implementation in Java7, see:

http://forum.jogamp.org/Issue-with-Java-3D-under-OpenJDK-7-Mac-OS-X-tp4025259p4028135.html

Harvey

On 02/21/2013 10:36 PM, hharrison [via jogamp] wrote:
> Thanks for testing Ernest,
>
> The offset problem is known about, and is likely a problem in the AWT
> implementation in Java7, see:
>
> http://forum.jogamp.org/Issue-with-Java-3D-under-OpenJDK-7-Mac-OS-X-tp4025259p4028135.html
>
http://jogamp.org/deployment/archive/master/gluegen_640-joal_404-jogl_921-jocl_752/
http://jogamp.org/git/?p=jogl.git;a=summary

Contains a CALayer fix / workaround, beside other fixes - hope it helps.

Will continue the OSX/Java7 bug-fix session next week.

~Sven

Thanks Sven, updated jogl-all.jar, jogl-all-natives-macosx-universal.jar, gluegen-rt.jar and gluegen-rt-natives-macosx-universal.jar = unfortunately exactly the same behaviour as before. Anything I can do to help?

I just tried on Oracle JRE7u15 and it still contains the position bug.

elotter, have you tried on OpenJDK 7u12 ? That works for me combined with Augusts fixes.
http://jdk7.java.net/download.html

Forgot to mention, that I tested the 1.6.0-pre6 with the OpenJDK 7u12 and it works (positioned correctly). Thanks

Thanks for testing!

Harvey

I successfully tested the 1.6.0-pre6 release on Mac 10.7.5 and 10.8.2, Apple Java 1.6.0_41, Oracle 7u15, 7u12/8ea with onscreen and offscreen Java 3D apps (no applets). All tests behaved as expected : the offset problem still exists, the resizing problem is solved.

While scanning the sources I found an obsolete line of code which I forgot to remove in JoglPipeline / QueryCanvas.addNotify() : 'nativeWindow.setShallUseOffscreenLayer(false);' (compare Jogl.Pipeline.createNewContext()).

Unfortunately, the recently published JOGL build is a regression http://jogamp.org/deployment/archive/master/gluegen_640-joal_404-jogl_921-jocl_752/http://jogamp.org/git/?p=jogl.git;a=summary . A new resizing problem occurred on 7u12/8ea: the size remains fixed and the scene will be stretched or compressed. Also my JOGL samples don't position correctly anymore http://forum.jogamp.org/Mac-OS-X-10-7-Oracle-JRE-7-Swing-integration-issues-td4027780.html.

In my Java 3D native OpenGL pipeline for Mac/7u12/8ea I choose following approach: when the Canvas3D becomes visible and is painted the first time the corresponding CALayer is created and its frame-property is set to the y-flipped Canvas3D's bounds relative to its parent window (neither relative to the screen nor to the parent component). Later bounds changes are only handled by JRE/AWT. This results in always correctly positioned Canvas3Ds. The z-order problem still remains and can only be solved by the JRE.

August

Thanks, I'll push out a fix for that tonight.

Had you given any more thought to how we might get rid of the QueryCanvas, I see from your comments
you had similar problems removing it.

Harvey

Up to now I haven't found an aproach how to create an OpenGL context for an onscreen Canvas3D within a NOT visible window/JFrame (similar to the implementations in the native pipelines).

August