Problems with new threading model in jogl1.1b10

OpenGL Development JOGL Development
#1

We are having many issues with jogl1.1b10. They are to do with the new threading model. Our rendering engine uses a single rendering thread to make calls to OpenGL. It manages both asynchronous and synchronous calls to OpenGL. It was working just fine with the old threading model!

When picking and printing we really need calls to OpenGL to occur synchronously. The new threading model makes this very difficult, resulting in immediate deadlock.
For example, if a pick is initiated from a mouse click, via the AWT event queue thread (AWT-EventQueue-0) it requests our rendering thread to perform the operation. We synchronize the AWT-EventQueue-0 thread with our rendering thread using wait, thus the AWT-EventQueue-0 thread issues a wait, which it is only released once the rendering thread has completed.

It is our rendering thread that interacts with the GLCanvas. It calls GLCanvas.display to get the rendering [picking] under way. This is when the deadlock occurs. GLCanavas.maybeDoSingleThreadedWorkaround calls EventQueue.invokeAndWait which blocks because AWT-EventQueue-0 is already waiting on our rendering thread!

Here is the call stack from the two threads:

Our Rendering Thread

wait() : 429, java.lang.Object
invokeAndWait() : 829, java.awt.EventQueue
maybeDoSingleThreadedWorkaround() : 220, net.java.games.jogl.GLCanvas
display() : 75, net.java.games.jogl.GLCanvas
…

AWT-EventQueue-0 Thread

wait() : 429, java.lang.Object
…
Synchronize with rendering thread
…
processMouseEvent() : 5100, java.awt.Component
…

I think that this scenario could be quite common amongst JOGL users; the current fix in jogl1.1b10 does not work well in such cases.

Currently the only way to revert JOGL back to the old method of rendering is via setting the property “jogl.1thread”, something like a static class initializer:

static
{
     try
     {
         AccessController.doPrivileged(new PrivilegedAction()
         {
             public Object run()
             {
                 System.setProperty("jogl.1thread", "false");
                 return null;
             }
         });
     }
     catch (Throwable e)
     {
         /* Exception handling goes here */
     }
 }

This works but since it requires privileges it means our jar file needs signing, something we would really rather not have to do. Is there another programmatic way, which does not require privileges, to force GLCanvas to render using the old method?

Any comments/suggestions? Thanks in advance

Alan Michael Gay

#2

Sorry that JOGL 1.1 b10 broke your application. Is there no way you can instead queue up your mouse events and process them over in your main animation loop?

Right now the only way to disable the single-threaded behavior is by specifying that system property. If you deploy via Java Web Start you can add a tag to the section of your JNLP file:


      <property name="sun.java2d.noddraw" value="true"/>

If you have control over the command line, you can add -Djogl.1thread=false to it. Feel free to file an RFE with the Issue Tracker on the JOGL web page about adding an API for this. You’ll need to request Observer status on the project if you haven’t already.

#3

Hi Ken,

Thanks for your rapid response. Our rendering engine is part of a toolkit/library. Thus the main animation loop is outside our control, and our toolkit is deployed in a multitude of scenarios. I will file an RFE about adding an API for this.

Thanks again

Alan

#4

I understand the issues regarding the change to singlethreaded behavior. But is there any specific reason that the single thread that does all the OpenGL work needs to be the AWT event queue thread?

The issue I’m facing is that I would like for the other swing elements to remain responsive while I create complex display lists. Currently, everything freezes for the duration of the display loop. I’d like to add a progress meter, or some kind of visual feedback so that the user doesn’t think that the app has frozen.

#5

The AWT event queue thread is the thread on which most of the AWT’s internal widget operations are performed. We’ve found through trial and error that ATI cards in particular seem to not behave well when there are concurrent widget operations occurring on both the AWT event queue thread and any other thread performing e.g. OpenGL rendering (the “hang upon resize” bugs seen in earlier releases).

I don’t have a good answer for your question; you might try breaking up your initialization work into smaller pieces. You also do have control over the buffer swapping of the GLCanvas, so you could draw a progress bar by manually swapping the front and back buffers periodically (though other Swing widgets would still be blocked). See the source code for the JCanyon demo source code for an illustration of this.

#6

Another problem related to the single thread model (linux only, when Animator is used ) :

When (carefully) integrating a GLCanvas in a Swing application containing splitpanes, i’ve ran into a repaint problem : it seems as if some dirty zones were lost during the resize / repaint process (not on the canvas, but on lightweight components around, like the other part of the splitpane).

So the windows remains full of gray rects until a major repaint occurs.

Things were fixed, either by turning off the jogl.1thread switch, or by inserting a Thread.sleep(1)/ Thread.yield() into the animator display loop.

It would be a good thing to add this yield() into the animator loop, or to make it optional with a switch.

System :
linux (mandrake 10.1)
jdk 1.5.0
Nvidia GeForce II with latests nv drivers.

Lilian

#7

[quote]Another problem related to the single thread model (linux only, when Animator is used ) :

When (carefully) integrating a GLCanvas in a Swing application containing splitpanes, i’ve ran into a repaint problem : it seems as if some dirty zones were lost during the resize / repaint process (not on the canvas, but on lightweight components around, like the other part of the splitpane).

So the windows remains full of gray rects until a major repaint occurs.
[/quote]
Do you have a small test case which reproduces this problem? If so, please file a bug with the JOGL Issue Tracker and attach it. Thanks.

#8

ok i’ve submitted the issue with a simple test case.

Sorry i’ve copy/pasted source code into the description instead of attaching the file (first issue submitted…)

Lilian

#9

Hi all,

I’m slowly converting all of my GL4Java applications to JOGL as it seems as though the Gl4Java project is now defunct. The threading model in JOGL is causing me a lot of headaches too, one of which is that when I add Popupmenu’s to my visuals, they completely stop rendering. Most of the Data I need to display are realtime oriented so I cannot afford for the Visual to stop and wait everytime the Event Queue gets a lengthy job (and I really like my Popups as they save me lot of screen realestate). Almost all of the applications I write have multiple OpenGL windows that need to be rendered constantly. I’ve also had issues where my application takes a very long time to start up (mind that this is exactly the same application that was written with GL4Java and posed no problems whatsoever under that library), on one of the threads here on the Forums this phenomenon was quickly debunked as a Driver Issue but I seriously doubt the validity of this conclusion. When I disabled the single threaded model, however, most of my problems disappeared, including the application startup problem. Thus I am almost completely certain that this is a thread contention issue.

As far as I can gather, the only reason this model was implemented was to accomodate the lack of robustness in ATI drivers, which, my company has found, is quite a common problem with their cards. That is why we’ve decided to exclusively use NVidia cards. My argument is; we shouldn’t be limiting ourselves simply because a company couldn’t be bothered to implement a decent driver solution. The Java and OpenGL cooperation is fast becoming a force to be reckoned with and ATI should do well to recognize this and fix the instability in their drivers.

#10

Louis,

I have slightly similiar problem to yours where
I require constant updates to both Swing and
JOGL. My solution was to bypass JOGL’s threading
mechanism and manage it all on my own.
That is, none of the JOGL calls are run on the
Event Dispatch Thread. I’m even skipping over
Component.reshape(…) and calling swapBuffers()
on my own. I’ve gotten fairly good results by
using a custom version of GLCanvas. There
might be something in forum thread ‘Smooth
scrolling’ that you will find useful.

The way JOGL is implemented this way is really
due to 3 issues combined: Swing, OpenGL context’s
single-thread requirement, and driver issues.

I do hope that JOGL can have an abstraction
layer that wraps this whole threading model
and that this layer is separated from main OpenGL
functionality. This way, experienced users can
bypass the safety nets and manage things on
our own while new users are protected from
most pitfalls.

.rex

#11

That’s pretty much what I’m doing now too, I’m using my own thread to handle display events but I’m still using the stock GLCanvas.

Since I’ve disabled the single threaded model, I’ve had issues with my reshape events, for some reason the Color Buffer is not being cleared correctly and I’m getting artifacts all over the canvas everytime I resize the window. Any ideas? I think my reshape events are being issued too early or something, or it might be something to with the swapping of the front and back buffers - I’ve tried various solutions to no avail.

HAve you encountered any such problems? It sounds as though a custom GLCanvas might solve it.

#12

Ok. Never mind, the reshape issue was a card problem. Everything seems to be working ok now.

I really do hope the jogl team will take note of the many problems this single threaded model is causing and implement an abstraction layer that will make it easier for developers to implement their own custom threading solution. I think that making the GLCanvas class “final” was a bit nasty.

#13

We’re definitely paying attention to the issues caused by changes like the switch to the single-threaded rendering model in JOGL. However we must target the largest possible audience with the default settings in the library and this switch has definitely improved the stability and portability of JOGL applications. Advanced users can always turn off the switch or reimplement portions of the library if necessary because it’s open source. In the forthcoming JSR-231 implementation the GLContext class will be exposed so it will be possible for the GLCanvas to be implemented using only public APIs in the library. At that point the GLCanvas will be made non-final.

#14

Great. Thanks Ken.

#15

Ken, do you have any news about JSR 231 ? (nothing new on jcp.org since 2004)

Lilian

#16

Most of the API changes have been decided upon but the implementation hasn’t started in earnest yet. We have been struggling with some licensing issues which we are hoping will be resolved this week at which point you should see more activity in the JOGL source tree related to JSR-231.