Problem with JOGL : Use of the AWT event queue?

OpenGL Development JOGL Development
#1

I might be wrong about this, but I believe that the use of the AWT event queue by JOGL may be problematic. Consider the following case which I have come across whilst trying to implement a JOGL application:

  1. I have window into which I am rendering OpenGL (using GLCanvas)
  2. I have a seperate window in which I am using Swing to draw a graph of nodes. These nodes can be dragged around by the user (by clicking and dragging with the mouse).

I am seeing a problem that when Vsync is enabled there is very noticable “lag” when the user drags nodes using the mouse. By that I mean that the node being dragged lags behind the mouse’s actual position. I suspect the reason for this is that swapBuffers is being called in the AWT thread, which is blocked until a refresh, which delays the processing of the mouse events and subsequent repaints necessary to implement to dragging functionality.

This is undesirable. Wouldn’t it be better if JOGL used a seperate thread to prevent these kind of unwanted interactions (and to increase performance, when AWT and JOGL are both used on multi-core processors)? As an aside, this would (presumably) also give developers better control when setting thread priorities.

Does anyone know of a workaround to this problem, or can anyone spot a mistake with my reasoning?

Thanks

#2

In the original version of JOGL, the GLCanvas handling was forced onto the AWT thread for stability across many platforms. There are ways to disable this, I would look at the Threading utility class although this may not work on as many computers. Another option is to switch to JOGL 2, which as better multi-threaded support and can even make windows without the use of AWT.

HTH

#3

Thanks for the information. I’ve updated my code to use JOGL2 as a first step, however I cant seem to find much information regarding threading.

Is there a simple way to switch the thread used in JOGL2 whilst still using Animator? Could you provide a simple example or link to an example where the awt event queue isn’t used?

#4

HI im looking for a way for escaping awt as well, a none awt window wont help me cause i have to plug it into the app frame. Any ideas?

#5

Unfortunately I don’t have time to do that right now. I’d look into the jogl2 demos, I believe they cover some examples.

Also, try adding:
Threading.disableSingleThreading() at the very start of your program. Then all the displays will run on the animator thread (I think)

#6

Thanks, Threading.disableSingleThreading() removes it from the awt thread but it gives some strange behavior. And the scene becomes not responsive ?

#7

Could you go into more detail about how you’re doing it? Are you sure that the threads have dead-blocked?

#8

I have an own implemented animator that runs in a thread of its own in the application. Its job is simple wait for a call from the application to render then render a single frame. I added the Threading.disableSingleThreading() to the engine start up. Then the application doesn’t refresh after a call to refresh the scene. It only refresh on resize of screen!

Hope this helps!

#9

Try -Djogl.1thread=worker or -Dopengl.1thread=worker (don’t know the right one) instead of Threading.disableSingleThreading()

#10

I tried that before but its buggy and experimental as ken once told me.

#11

it’s a pity…

How do you render the single frame? GLCanvas.display()? Are you under windows and have you specified the -Dsun.java2d.noddraw=true -Dsun.awt.noerasebackground=true properties?

#12

i use drawable.display()

Yes i am under windows but dont which to be specific

I have -Dsun.java2d.noddraw=true but not the second (what does it do?)

Thanks for your help

#13

Btw does -Dsun.java2d.noddraw=true have an effect on the text quality (bcuz im getting very bad quality) but i remember it is essential but dont remember for wat

#14

Maybe it disables ClearType on windows, but I don’t know. Without this setting you are risking conflicts between the OpenGL and the DirectX pipeline on driver level. Without the AWT threading model I encountered grey screens and application freezes under Vista, but even with the AWT threading model enabled you can’t be sure to have robust behaviour under windows.

#15

I confirm cylab is right, I still get some freezes under Vista with JOGL 1.1.1b when I move the mouse but not on all machines and only when used inside JMonkeyEngine 2, not with my previous tiny engine.

#16

I never had any problem with active rendering following the receipt in the Killer Game Programming in Java online chapters. You don’t even need a GLCanvas to draw with OpenGL. As long as you follow the precautions explained in the book it should work all right.

#17

we encountered this with my application on one of the testing team machines (using jogl 1.1.1), so yiou mean if I add -Dsun.awt.noerasebackground=true it will not show. Can you explain what exactly does it do.

So this will typically be the cause of the aliased text, any work around?

#18

In any case you would need both (-Dsun.java2d.noddraw=true -Dsun.awt.noerasebackground=true) for the best result. The noddraw property is mandatory, otherwise anything could happen (including rendering thread deadlocks). The noerasebackground just suppresses filling the canvas with the awt background color. In your case I could think of your Animator refreshing the screen outside of the AWT event thread but also causing a repaint event on the canvas in the next AWT thread iteration which will then fill it with the grey background color - effectively overwriting you refrehed scene.

That’s my guess and I don’t think there is an (easy) workaround, but I am no java2d expert. Maybe ask at the sun forums.

#19

Thanks for the explanation

The display which is called from the animator is jumping to the awt thread, i did the always alive thread of the animator (one the targets, is to try to get as much out of the awt thread). Its not overwriting the scene but on startup u see a grey backgound. should i overwrite the repaint?