GUI thread is blocked

OpenGL Development JOGL Development
#1

Hello, i have a little problem with det gui thread getting blocked.
I have an example of what i mean:

public class Block extends JFrame implements GLEventListener
{
private GLCanvas canvas = null;
private JPanel panel;
public Block()
{
panel = new JPanel();
panel.add(new JButton(“test”));
add(panel,BorderLayout.EAST);
canvas = new GLCanvas();
canvas.addGLEventListener(this);
add(canvas);
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
setSize(300,300);
setVisible(true);
}
public void display(GLAutoDrawable glDrawable)
{
while(true);
}
public void displayChanged(GLAutoDrawable glDrawable, boolean modeChanged, boolean deviceChanged)
{}
public void init(GLAutoDrawable glDrawable)
{
}
public void reshape(GLAutoDrawable glDrawable, int x, int y , int width , int height)
{}
public static void main(String args[])
{
Block b = new Block();
}
}

When i run this example, it is not possible to push the button, i just wondered if it’s possible to use gui components even if
gl is running at the same time.

#2 
while(true);

is a very VERY tight loop. It’ll almost certainly starve all other threads, including the awt dispatch thread(s).

But assuming that’s not the problem (like if it still hangs after adding a sleep or two to that loop), here’s a theory:

GLCanvas.paint gets called by the awt dispatch thread. That method calls (via a lot of thread magic) the display method.
So in other words, the awt dispatch thread is busy while you’re doing the rendering, and can’t do anything else.

#3

But in the real program i dont have the loop, but the problem is that the gui buttons is blocked during image reading, and i need to use them during the image reading.

#4

I think my theory might be correct then.
If the opengl rendering is done from the awt dispatch thread, or if it’s blocked while the rendering is being done, the application will behave like you’ve said.

I suggest you use direct context control instead of using GLCanvas.

#5

If this is true then do you know any good way of doing input from file? To avoid freezing the entire application when loading models and textures?

#6

but if u look away from the code above.
i have a program that in the init function under GLEventListener reads in some modells, and each one of the model read’s in images. then everything will be blocked until the reading is done, isn’t it possible to run that in a new thread instead?

#7

There might be another workaround by using the TextureIO util class from Ken Russel discussed in this Thread: http://www.java-gaming.org/forums/index.php?topic=12063.0 Afaik it’s designed to load images in background to not block the AWT event thread.

There was also an enhancement filed (https://jogl.dev.java.net/issues/show_bug.cgi?id=191) to move the OpenGL work to another thread which seems to be implemented in newer versions. Maybe you’ll just have to try a new nightly build!?

#8

As cylab mentions the current JOGL nightly builds might solve this problem for you. We are still working through some stability issues with the new worker thread and locking model.

In general I would recommend writing your own background worker thread to load models and textures if you don’t want to block the rest of your app.

#9

Maybe this is a silly question, but is all i have to do is to create a new Thread then, or do i have to do something to do gl calls from the new thread? I have tried to use the Threading.isSingleThreaded() and then i got true. And is it some examples out there which uses the TextureIO and Texture classes for loading and binding textures? I tried to use it loading .png images, and i think it’s read because i get the width and the height of the image, but it’s all dark:( Is the Texture classes doing the transformations like flipping automaticly?

#10

You would need to write your own worker thread class to do some of the non-OpenGL loading work and then feed back the resulting objects at a later point to the main thread in order to do the OpenGL work. This is how I would recommend structuring things for best stability.

[quote]And is it some examples out there which uses the TextureIO and Texture classes for loading and binding textures? I tried to use it loading .png images, and i think it’s read because i get the width and the height of the image, but it’s all dark:( Is the Texture classes doing the transformations like flipping automaticly?
[/quote]
There aren’t any examples yet of background loading of textures. The TextureIO class can be used to implement background loading; you can create a TextureData in a background thread and hand that back to your rendering thread for conversion into a Texture object (which requires an OpenGL context to be current).

The JCanyon demo’s source code has an example of a worker thread used to page in texture data.

#11

I have outlined a possible way to pass GL commands to the rendering Thread in a different discussion.

The main idea would be to start a new Thread that does all GL unrelated work and pass a GLAction that binds the texture to the GLQueue, once the loading is finished.