Problem with JSR231 April 20 release

OpenGL Development JOGL Development
#1

Hi

We have encountered two issues when shifting from the Februrary 17 release to April 20.
The code works without issues with the February 17 release and the issues appear on both
OSX and WinXP and Java 1.5 (ATI and Nvidia hardware). When rendering we use a external context mechanism, however the actual context is still an GLCanvas for debug purpose. The issues are:

Issue1:

When building mipmaps we get a “NullPointerException”

Exception in thread “main” java.lang.NullPointerException
at com.sun.opengl.impl.mipmap.Mipmap.closestFit(Mipmap.java:242)
at com.sun.opengl.impl.mipmap.Mipmap.gluBuild2DMipmaps(Mipmap.java:687)
at javax.media.opengl.glu.GLU.gluBuild2DMipmapsJava(GLU.java:1523)
at javax.media.opengl.glu.GLU.gluBuild2DMipmaps(GLU.java:1579)
at com.agency9.server.resources.optimized.GLTexture2D.allocate(GLTexture2D.java:21)
at com.agency9.server.resources.optimized.GLTexture2D.(GLTexture2D.java:16)

Issue2:

The second issue comes when we try to assign a glVertexPointer where we alos get an “NullPointerException”.


java.lang.NullPointerException
at com.sun.opengl.impl.FunctionAvailabilityCache$Version.(FunctionAvailabilityCache.java:296)
at com.sun.opengl.impl.FunctionAvailabilityCache.initAvailableExtensions(FunctionAvailabilityCache.java:133)
at com.sun.opengl.impl.FunctionAvailabilityCache.isExtensionAvailable(FunctionAvailabilityCache.java:104)
at com.sun.opengl.impl.GLContextImpl.isExtensionAvailable(GLContextImpl.java:328)
at com.sun.opengl.impl.macosx.MacOSXGLContext.isExtensionAvailable(MacOSXGLContext.java:229)
at com.sun.opengl.impl.GLImpl.isExtensionAvailable(GLImpl.java:27851)
at com.sun.opengl.impl.GLImpl.initBufferObjectExtensionChecks(GLImpl.java:27994)
at com.sun.opengl.impl.GLImpl.checkArrayVBODisabled(GLImpl.java:28064)
at com.sun.opengl.impl.GLImpl.glVertexPointer(GLImpl.java:25295)
at com.agency9.server.kernels.first.KernelImplementation.setMesh(KernelImplementation.java:263)

Cheers
// Tomas

#2

Both look to me like bugs in application code where there is either no current OpenGL context or no current OpenGL context at the JOGL level (i.e., you need to call makeCurrent() on an “external” GLContext object).

Please provide test cases for these problems if you need help tracking them down.

#3

[quote]Both look to me like bugs in application code where there is either no current OpenGL context or no current OpenGL context at the JOGL level
[/quote]
This was my initial reaction, but the code is stable and works with both the January and February releases of JOGL. Has the initialization process or the internal context mechanism changed between the Februaury and the April release ?

[quote]Please provide test cases for these problems if you need help tracking them down.
[/quote]
I’ll see if I can extract a simple testcase, if I can’t work this issue out.

Thanks
// Tomas

#4

I have attached a simple testcase of the issue. The problem seems to be that I don’t get an context, but the big question is why ?
The testcase works with the Januaray and February release on OSX but not the April 20 release. The testcase uses the external context mechanism (setup against GLCanvas for test purpose) since the end product will be embedded in a legacy applictaion.

Thanks for the help
// Tomas

#5

I’m on my way out the door right now but without looking at your test case I think I know what is happening. The change between the February and April releases in this area is that GLContext.makeCurrent() now looks to see whether another context is current right now and, if so, releases it before making the new context current. This means that the external GLContext is going to cause the GLContext of the GLCanvas to be released when it is “made current”.

Keeping at least part of this behavior is important for some kinds of applications which want to call makeCurrent() over and over again on multiple contexts without calling release(). It might be possible to change the implementation to cause the current context to be “unlocked” as opposed to fully “released” since a new context is going to be made current anyway. This should restore the old behavior. Please file an RFE about this and attach your test case.

Note that the external GLContext should still work in the context of the real application.

#6

Done Issue 224.