Threading.isOpenGLThread() seems wrong with Java2D Pipeline

OpenGL Development JOGL Development
#1

With Java2D Pipelining enabled, my OpenGL thread has name “Java2D Queue Flusher”. No problem there. But Threading.isOpenGLThread() returns true for both that OpenGL thread, and the EDT with name “AWT-EventQueue-0”. I think this is wrong because everything else shows that I am running a single-threading-OpenGL environment and that “Java2D Queue Flusher” is it. Thread.currentThread() reports from the GLEventListener callbacks always report that Thread. Threading.isSingleThreaded() reports true. I understand that the Threading class is aimed towards typical setup, but the documented constraint is single-threading-OpenGL, and that is what I have. If I have a bad deduction here or am missing something, I’d appreciate it if somebody would take the time to correct me.

My concern isn’t theoretical.

  • This is making it impossible for me to enforce proper thread usage as is recommended by all AWT threading authorities and all JOGL threading authorities.
  • Just as importantly, I need to toggle between threads… the exact use case for Threading.invokeOnOpenGLThread(Runnable), but my attempts to use this throw:
    javax.media.opengl.GLException: Should only call this from other threads than the OpenGL thread
    While I agree that what is says is true… one should not call invokeOnOpenGLThread from the OpenGL Thread… I am not doing that! I am calling the method from the EDT thread, and that is why I need to switch to the OpenGL Thread. I tentatively guess that something underneath invokeOnOpenGLThread calls the broken isSingleThreaded.

It is going to cause major change control and distribution problems for me if I have to override Threading.isSingleThreaded or Threading.invokeOnOpenGLThread. I am stuck with JOGL v. 1.1.1 due to dependencies of another third party library which everything revolves around.

I’m going to hit the JOGL source code now. If anybody can point out anything wrong with my reasoning, has a tip or a work-around, or even an idea of something to try, please reply.


UPDATE: Working with the source code now, I’ve learned that (a) even though these are javax.* classes, I can still override without modifying the JOGL distributable; and (b) I am not going crazy, this problem is documented in the JOGL source code. The JOGL 2.0 fixes for the numerous and significant JOGL thread contention issues are not amenable to backporting. Looks like I am going to have to do a lot of 3D work in the EDT until I am able to upgrade to use JOGL 2. :frowning:

#2

Why aren’t you able to upgrade to use JOGL 2? because of JMonkeyEngine 2.0? Has someone put our fixes into the trunk?

#3

Probably has nothing to do with a 3rd party library using JOGL 2 but instead that JOGL 2 is still buggy and subject to changes. It’s in its infantile stages, gouessej, it’s not a bad thing that people are hesitant to start porting all of their code over.

#4

Of course you’re right, you know I still use JOGL 1.1.1a for TUER but I know Blaine uses JMonkeyEngine 2.0 and I was speaking about the fixes of the JOGL renderer of JMonkeyEngine 2.0 that uses JOGL 1.1.1.