Java3D 1.6 crashes JVM

Hmm, I'm also finding reports like this one:

http://www.eclipse.org/forums/index.php/t/696981/

I wonder if perhaps this one isn't Java3D's fault....but I'll stare at it some more.

Harvey

Digging into the JDK...around line 2795:

2793    private void  [More ...] addToWindowList() {
2794    synchronized (Window.class) {
2795          Vector<WeakReference<Window>> windowList = (Vector<WeakReference<Window>>)appContext.get(Window.class);
2796          if (windowList == null) {

Sooo, another null appcontext problem, I'll see if I can also do the workaround in the queryproperties case, as the pipeline
may not be initialized yet either....fun!

Harvey

On 05/12/2014 06:17 PM, hharrison [via jogamp] wrote: Maybe you can consider my remarks here
  <https://jogamp.org/bugzilla/show_bug.cgi?id=1004#c4>

.. i.e. launching your Java3D master-thread (sic)
or any thread utilizing AWT w/ an AppContext aware ThreadGroup,
see AppContextInfo.
This approach does not need to patch the AppContext ThreadGroup mapping.

~Sven

I agree with Sven's comment about the generic solution that would address the problem for all scenarios.

However, for queryProperties can't we come up with a way that does not require creating a JFrame? can't be query the graphics card directly to read its capabilities?

The current way is not very useful because:
a) it's slow, and at startup every millisecond counts
b) it can easily fail for old graphics cards or those graphics card that have wrong video driver installed. The whole point of reading capabilities is to prevent unexpected failures. As it stands right now it's not very useful.

How do you OpenGL developers do this?

On 05/12/2014 07:30 PM, runiter [via jogamp] wrote:
> I agree with Sven's comment about the generic solution that would address the
> problem for all scenarios.
>
> However, for queryProperties can't we come up with a way that does not require
> creating a JFrame? can't be query the graphics card directly to read its
> capabilities?

I am not so familiar w/ Java3D, are these caps related to GLCapabilities ?
If so, you can always query all GLCapabilities for a specific device
w/o the need to create a dummy window. This is b/c we do query them
at JOGL initialization, which didn't exist in JOGL1.

<http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/javax/media/opengl/GLDrawableFactory.html#getAvailableCapabilities%28javax.media.nativewindow.AbstractGraphicsDevice%29>

Further more, one can also query available GLProfiles for one device:

<http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/javax/media/opengl/GLProfile.html#getMaxProgrammableCore%28javax.media.nativewindow.AbstractGraphicsDevice,%20boolean%29>
.. etc ..

~Sven

Great then, we can simply call those JOGL methods from queryProperties without need to create a new JFrame.

If we can return everything Java3D used to return that should work fine. The following is what Java3D queryProperties used to return:

compressedGeometry.majorVersionNumber = 1
compressedGeometry.minorMinorVersionNumber = 2
compressedGeometry.minorVersionNumber = 0
doubleBufferAvailable = true
native.renderer = GeForce 8800 GTS/PCI/SSE2
native.vendor = NVIDIA Corporation
native.version = 3.2.0
sceneAntialiasingAvailable = true
sceneAntialiasingNumPasses = 1
shadingLanguageCg = false
shadingLanguageGLSL = true
stencilSize = 0
stereoAvailable = false
texture3DAvailable = true
texture3DDepthMax = 2048
texture3DHeightMax = 2048
texture3DWidthMax = 2048
textureAnisotropicFilterDegreeMax = 16.0
textureAutoMipMapGenerationAvailable = true
textureBoundaryWidthMax = 1
textureColorTableSize = 0
textureCombineDot3Available = true
textureCombineSubtractAvailable = true
textureCoordSetsMax = 8
textureCubeMapAvailable = true
textureDetailAvailable = false
textureEnvCombineAvailable = true
textureFilter4Available = false
textureHeightMax = 8192
textureImageUnitsCombinedMax = 32
textureImageUnitsMax = 32
textureImageUnitsVertexMax = 32
textureLodOffsetAvailable = false
textureLodRangeAvailable = true
textureNonPowerOfTwoAvailable = true
textureSharpenAvailable = false
textureUnitStateMax = 4
textureWidthMax = 8192
vertexAttrsMax = 10

On 05/12/2014 09:43 PM, runiter [via jogamp] wrote:
> Great then, we can simply call those JOGL methods from queryProperties without
> need to create a new JFrame.
>
> If we can return everything Java3D used to return that should work fine. The
> following is what Java3D queryProperties used to return:

...


We will need to add this information query and storage in JOGL,
so it can be picked up at initialization.

Can you point me to the Java3D classes holding the info
so I can 'copy' those to JOGL ?

I would appreciate we can work on this task together ..

In short: We can do this within the 2.x JOGL branch!

~Sven

Some of those properties have been hard-coded at this point as they no longer have any internal function....I will produce a mapping of what properties are actually being queried, and what is being called on the jogl side (I started that awhile ago, will fisih and get it over to you)

It's a bit tricky because the query can come from the Java3D main thread, but it can also be called from user code before Java3d is even initialized.

I'll open a Java3d issue this week with whatever I have.

Harvey

But if you have time before I get to it, the best starting point is Canvas3D.createQueryProps(), you can trace the rest from there.

On 05/13/2014 01:07 AM, hharrison [via jogamp] wrote: That would be great .. if we can move those queries to JOGL's initialization,
I guess we even could change GLProfile/GLDrawableFactory in a way to accept
a custom GLRunnable, which then would perform the custom query
while performing JOGL's default initialization.

> But if you have time before I get to it, the best starting point is
> Canvas3D.createQueryProps(), you can trace the rest from there.

Thank you.
I will wait of course.

Based on your results, we can decide whether we offer the data
in JOGL the static way .. or use such a custom query.

~Sven

> Harvey

Thinking with my jaamsim hat on, we'd also be pretty happy with such a query mechanism and not have to go the query context route, so I think this maybe be a pretty generally useful bit of functionality.

Harvey

Hi

Sven Gothel wrote

That would be great .. if we can move those queries to JOGL's initialization,
I guess we even could change GLProfile/GLDrawableFactory in a way to accept
a custom GLRunnable, which then would perform the custom query
while performing JOGL's default initialization.

I like your idea. In my humble opinion, JOGL shouldn't contain a data type to represent the capabilities, this is rather the job of an engine but your suggestion would be useful for several kinds of operations. I could use it in Ardor3D too, to give access to the capabilities very early without having to create (explicitly) a window.

In my humble opinion, we should have a clear separation of concerns, JOGL shouldn't manage too much things, nothing prevents us from moving some utilities into a separate subproject.