I am having trouble that the thread keeps locking up causing the application to become unresponsive. Please see below how I have created and installed my AppState.
MyState works fine with no code in update(); but as soon as I put some code in it locks up.
I know for a fact that the calls to other classes return because it is code I have been using for a long time. However, that said there are several synchronizations and calls to heavyweight awt to display debugging information.
The question I have for someone experienced with the JME render thread is, what is the most likely cause for the rendering thread to lock up when it calls tried and tested code?
The following is the SimpleApplication instantiation code…
public MySimpleApplication()
{
super(new StatsAppState(),new MyState());
}
Here is the code for MyState…
public class MyState extends AbstractAppState
{
public void update(float _timePerFrame)
{
MyClass.staticCall();
MyClass2.anotherStaticCall();
MyClass3.getSingleton().instanceCall();
}
}
I realise you may be thinking that it is the content of these calls which is causing the render thread to lock up but if I make these calls from a different thread they all perform as expected.
Does the render thread have to return within a certain time?
Is a synchronization lock experienced with the event queue?
Yes, you are right and I appreciate this in my code. The processing involved is minimal and non-existant in my test. However, even if is it expensive I would expect the FPS to drop considerably, not lock up.
well if that above is the only thing you do then you probably have screwed up something inside that three lines, beside the fact that you somehow managed to violate java code conventions and have 2 static calls and 1 singleton in just 5 lines of code.
How on earth should we know what you do in that three functions?
If i would have to guess your frame synchronisation code might not be bulletproof
Oddly, although my test routines performed arbitrary administrative routines and hence didn’t call any JME3 functionality, the locking up seems to be caused by the AppState being called before the canvas context has been added to the desktop frame.
Maybe, the lock up occurs if the canvas is added to the desktop frame while the AppState is in mid update. This would account for the odd occasion where it would run ok.
My solution is I now have a boolean which is set true after the canvas has been added and the AppState update returns immediately if this is not set. I now appear to be experiencing a confident level of stability.
I would appreciate some insight if this is sufficient or if there are other things I need to be aware of.
The callback to say the canvas had been added occurred before the first AppState update so it was a mute point.
I have got it down to so that the AppState immediately returns on the first call and thereafter it all seems to work fine. I guess the first render loop is initialising stuff and is a bit delicate.
Nope. There is nothing in that statement that is true. Everything has been initialized by the first update. There is something in your code that was blocking indefinitely but we can’t see that code so it is impossible to say what.
public static class MyAppState extends AbstractAppState
{
public void update(float _timePerFrame)
{
if(!Host.isLive())return;
DB.print(“MyAppState.update running #1”);
Pr.update(_timePerFrame);
DB.print(“MyAppState.update running #2”);
}
}
A static call…
public final class Host
{
private boolean live=true;
public static boolean isLive()
{
return live;
}
}
Another static call…
public final class DB
{
private static TextArea ta=new TextArea();
public static void print(String _s)
{
ta.append(_s+"\r\n");
}
}
Another static call…
public final class Pr
{
private static Pr pr=null;
public static void update(float _tpf)
{
if(pr==null)return;
//never gets here in the test.
}
}
Here is all the code my AppState executed after I had strimmed everything out upon experiencing the problem. I am still experiencing the problem with this exact code.
The line which causes the render thread to block is…
ta.append(_s+"\r\n");
If I inhibit the AppStat on its 1st call then subsequent calls to the above line do not cause the thread to block.
Do you have any idea why appending text to a TextArea will cause the render thread to block?
Regards
Yes, so you are trying to get the AWT thread to play nice with the rendering thread and they aren’t happy about it. You’ve created a deadlock because AWT is waiting for the display to finish setting up and JME is not waiting for AWT.
Wrap your text area update in a SwingUtilities.invokeLater() and you’ll be fine.