Frame briefly opening and closing during Java3D init

I reported this problem before.
Since Java3D pre11, everytime the following line is called, a Frame briefly opens and closes:

GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getBestConfiguration(template);

I managed to track it down to this line:

https://github.com/hharrison/java3d-core/commit/8593fa0991feb9c9baa85a83269fc50c755dff80#diff-43a97f7278c01787e8acab6ac40d668bR8371

What is the purpose of this commit? And is there anything that can be done to prevent opening the Frame?

runiter,
This code is before my time, but I've never seen a way to get the best graphic configuration with having the frame display, I think it's because most windowing system can't query the hardware capabilities without reserving actual screen real estate. Certainly plenty of c++ coded applications put up a tiny blank window before resizing to the desired resolution.

The only other option I can think of to use if you really want to get rid of the flashing square is
GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
GraphicsDevice gd = ge.getDefaultScreenDevice();
GraphicsConfiguration[] gcs =  gd.getConfigurations();

Then pick the configuration that matches what you want

But of course knowing what the user wants requires a pile of display selection dialog code etc.
Then you also want to ask full screen or not, pixel depth, AA, anisotropic, stereo, possibly stencil bits, z bits etc.

I've got some code that does some of teh screen resoltion detection and dialog options here:
https://bitbucket.org/philjord/3dtoolsdesktop/src/08001308ea04dbc5b995ddfd86124d8379889858/3DToolsDesktop/src/awt/tools3d/resolution/?at=master

But it's only about half way to what you'd need.

Thanks Phil, your code seems useful. I'll take a look.
Your explanation makes sense, but if it's true then I wonder Java3D didn't need to do this before pre11 version?

Also, this may be a good time to hear how exactly does Java3D (and JOGL) select a graphics configuration?

I tried your suggestion of gd.getConfigurations() but that only returned a single configuration. This can't be! I'm sure JOGL find more possible configurations than the one returned by getConfigurations(). What is it that JOGL does that gd.getConfigurations() doesn't?

Okay how about this solution:

In order to prevent Frame from briefly showing Java icon in taskbar, use awt Window or awt Dialog instead of awt Frame here:
https://github.com/hharrison/java3d-core/commit/8593fa0991feb9c9baa85a83269fc50c755dff80#diff-43a97f7278c01787e8acab6ac40d668bR8362

Is this possible?

If it's possible, it will be a smarter solution.

I've raised a bug to track it, once I start putting together the next release I'll ensure it's in there, very easy change.

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

 

Julien,

I'm very busy now getting the ES2 gear to go on Android and work well, but I'll be available possibly end of August to put together a maintenance release for Java3D with a bunch of minor bug. That will give me a chance to learn how to get a release done.

Then shortly after that I'll start putting the ES2 pipeline together for a release.

I hope that you code against Java3D 1.7.0, note that this release uses different package names. Otherwise, you'll have to make a pull request against my repository with your bug fixes so that Java3D 1.6.0 and 1.7.0 benefit of them.

Thank you all for working on this fix.

Out of my own curiosity, could someone explain why creating a new frame or dialog is needed for Java3D, but not so for Ardor3D or JOGL itself? For example I looked in Ardor3D code and they don't seem to create a new Frame or Dialog during graphics configuration initialization.

Reminder: Ardor3D != JogAmp's Ardor3D Continuation

The former is dead, the latter is alive.

A little bit more things are up to the developers in JogAmp's Ardor3D Continuation and it isn't designed to support several kinds of hardware acceleration bound to low level AWT mechanisms unlike Java3D. JogAmp's Ardor3D Continuation uses JOGL a lot more directly than Java3D, it drives it a lot easier to maintain and more reliable whereas Java3D can stop working when AWT gets broken somehow.

Hi Julien,

gouessej wrote

Reminder: Ardor3D != JogAmp's Ardor3D Continuation

The former is dead, the latter is alive.

A little bit more things are up to the developers in JogAmp's Ardor3D Continuation and it isn't designed to support several kinds of hardware acceleration bound to low level AWT mechanisms unlike Java3D. JogAmp's Ardor3D Continuation uses JOGL a lot more directly than Java3D, it drives it a lot easier to maintain and more reliable whereas Java3D can stop working when AWT gets broken somehow.

How is JogAmp's Ardor3D Continuation more reliable even when AWT gets broken, particularly if using it with Swing?

Tom

At first, it doesn't rely on the same parts of the Swing/AWT API and a lot less. As JogAmp's Ardor3D Continuation's canvases directly extend JOGL canvases, if something gets broken in AWT, it might break JOGL canvases whereas it's totally different in Java3D which uses a plain AWT canvas, Canvas3D directly extends java.awt.Canvas. The source code of Java3D canvases is harder to maintain because it was designed to support Direct3D and OpenGL, it manipulates AWT graphics configurations, devices, environments, events, ... JogAmp's Ardor3D Continuation uses Swing and AWT as few as possible whereas Java3D does exactly the opposite, it's strongly tied to AWT.

Secondly, it provides a canvas based on NEWT but using a bridge with AWT, JoglNewtAwtCanvas based on JOGL NewtCanvasAWT. It's possible to use NEWT as much as possible but still put the canvas into a Swing/AWT GUI. Then, the source code depending on NEWT isn't affected by AWT bugs and limitations and can be reused in a pure NEWT canvas, i.e JoglNewtWindow.

Thirdly, JogAmp's Ardor3D Continuation wraps some nice AWT-free utilities to load images, it's designed to work without AWT. Actually, you can use a compact profile without AWT to build JogAmp's Ardor3D Continuation except ardor3d-jogl-awt and ardor3d-awt of course.

However, Phil will provide a better way of using Java3D based on NEWT to make it work under Android but the AWT side will remain unchanged and weak.

Thanks gouessej, that explanation clears up everything.

I have two follow-up questions:

1) What's an example of a scenario where AWT gets broken and causes Java3D to fail? AWT is supposed to be a mature library, I have a hard time imagining how it's broken.

2) Few of my customers report the following Java3D error:

javax.media.j3d.IllegalRenderingStateException: Java 3D ERROR : OpenGL 1.2 or better is required (GL_VERSION=1.1)

The version of Java3D is 1.6.0-pre9 which is before the new Frame() code was added.
Do you think this error is related to the broken AWT issue that is now fixed by using new Frame() code?

runiter wrote

1) What's an example of a scenario where AWT gets broken and causes Java3D to fail? AWT is supposed to be a mature library, I have a hard time imagining how it's broken.

AWT seems to be less actively maintained as Oracle focuses on OpenJFX and JavaFX. This is an example of broken AWT feature in Java 1.9:
https://bugs.openjdk.java.net/browse/JDK-8160421
Unfortunately, it affects JOGL too. I see sometimes some troubles with multiple monitors too under some operating systems. Moreover, the AWT fullscreen mode under GNU Linux is broken (it was already broken in 2006) and has never been fixed. Then, it's impossible to write a fullscreen software with Java3D working on all platforms supported by Java.

runiter wrote

2) Few of my customers report the following Java3D error:

javax.media.j3d.IllegalRenderingStateException: Java 3D ERROR : OpenGL 1.2 or better is required (GL_VERSION=1.1)

The version of Java3D is 1.6.0-pre9 which is before the new Frame() code was added.
Do you think this error is related to the broken AWT issue that is now fixed by using new Frame() code?

No it is related to another unfixed bug in JOGL, some ImageJ users reproduce it too. However, it may happen when no true OpenGL driver is available, then the Microsoft GDI renderer (supporting only OpenGL 1.1) is the only available driver :(

runiter,
For the GL_VERSION=1.1 bug please see http://forum.jogamp.org/Java-3D-crash-or-flickering-tp4035074p4037031.html