Hi,
I’m getting a bit of a funny deadlock issue with an application I’m building which uses JOGL together with Swing and AWT.
I have a class which extends Thread which is my repaint Thread. It has an ArrayList of JFrames (including the frame with the JOGL canvas in it) and another ArrayList of classes extending from an extension of JFrame used for all my Swing/AWT frames. There is a synchronized add() method to each arraylist, and the run() method periodically calls a synchronized private method which calls repaint() on all the panels and display() on the GL canvas (the rest of the run loop is not synchronized). I’m not using an Animator class.
This all works fine until the user presses a button which causes the Event Dispatch Thread to call the add() method on the extended JFrames arraylist, when it deadlocks. If I profile the app, I can see that it is the Event Dispatch Thread that is waiting on the monitor, and never seems to get into the add() method.
Removing the ‘synchronized’ from either the add() method or the repaint block lets the programme run, but I’ve solved it a bit more robustly by wrapping the call to GLCanvas.display() in a SwingUtilities.invokeLater(new Runnable(){}); block (ie call it from the Event Dispatch Thread after the event queue is cleared).
Just wondering if anyone can shed light on why this is doing it, and whether my solution is a good one ? Does the GLCanvas.display() method keep the monitor on the object calling it somehow, even after it’s returned ?
Cheers