Strange Deadlock in Window.setBackground()

Newbie & Debugging Questions
#1

So 1 out of 150 application launches causes a deadlock in the java vm. I traced the code down to a single line

w.setBackground(Color.GREEN);

Where w is a Window object.

Like I said this does not happen each and every launch just 1/150.

What I mean by deadlock is in my terminal window I can do ctrl C and there is no response :o. Ctrl Z kills the process but leaves the window open (in fullscreen … with no decorations I mind you).

Any ideas? Maybe a delay from creating the window to changing properties?

#2

Do you call that method on the event dispatch thread (EDT)?

Try http://download.oracle.com/javase/6/docs/api/javax/swing/SwingUtilities.html#invokeLater(java.lang.Runnable)

#3

I Create a JFrame. Remove decoration and remove re sizable so it is a plain screen. Then I set the full screen window of the graphicsdevice to the jframe. Then I use getFullScreenWindow and set font, background, and foreground in that order. Deadlock occurs at the set background. Figured if I commented it out it would just lock up at the set foreground. I probably am not setting enough time between creating the full screen window and getting it again. Its probably giving me some other window.

#4

As CommanderKeith said: do you call that method on the event dispatch thread (EDT)?

#5

If you don’t know what the EDT is, then you’re probably not doing it right.

#6

No not from edt. Should I be?

#7

Yes. Only manipulate AWT and Swing objects on the AWT event dispatching thread or you’ll get deadlocks and weirdness, pure and simple.

Cas :slight_smile:

#8

While I’d agree with everyone telling you to put everything on the EDT, that still might not fix the problem. Why are you not setting up all the properties (font, foreground, background, etc,.) on the frame prior to making it fullscreen? Various things I’ve read (though nothing I’d call concrete proof - anyone?) suggest that bits of FSEM can / will happen asynchronously, and the window might not be fully set up by the time you call getFullScreenWindow(), and therefore the native peer not in any mood to play ball! :slight_smile:

#9

Yeah try to have setFullScreenWindow your last command, I remember it gets messed up if you don’t

In my Java2D Display Manager, which I don’t use for fullscreen anymore, but it did work, I have something like


private void init(Frame fr)
    {
    	ourDevice = GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices()[0]; //failsafe
        
        //find primary screen device
        GraphicsDevice[] allDevices;
        allDevices = GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices();
        for (int i=0;i<allDevices.length;i++)
  	  {
      	  	java.awt.Rectangle bounds = allDevices[i].getDefaultConfiguration().getBounds();
  			java.awt.Point origin = bounds.getLocation();
  			if (origin.x == 0 && origin.y == 0 && allDevices[i].getType() == GraphicsDevice.TYPE_RASTER_SCREEN)
  			{
  				ourDevice = allDevices[i];
  				break;
  			}
  	  }

        if (fullscreen)
        {
            fr.setUndecorated(true); // Sun Java Bug ID: 5034393
  	  			   				   // Undecorated BEFORE display sets
            ourDevice.setFullScreenWindow(fr);
            int colordepth = ourDevice.getDisplayMode().getBitDepth();
            try
            {
                  ourDevice.setDisplayMode(new DisplayMode(width,height,colordepth,0));
            }
            catch(IllegalArgumentException k) // failsafe
            {
          	  k.printStackTrace();
                width = FAILSAFE_WIDTH;
                height = FAILSAFE_HEIGHT;
                ourDevice.setDisplayMode(new DisplayMode(width,height,colordepth,0));
            }
            System.out.print("Fullscreen Mode: ");
        }
        else
        {
            fr.setVisible(true); //otherwise bufferStrategy throws 'Component must have a valid peer' Exception.
            fr.setBounds(0,0,width,height);
            fr.setLocationRelativeTo(null); // middle of screen
            System.out.print("Window Mode: ");
        }
    }
#10

Thanks for the sample. I was doing those in that order. I set what settings that I could in the EDT. Then what I couldn’t I set ater a short delay. I have yet to encounter a deadlock.

#11

Short delay = hackery. Expect a deadlock.

Cas :slight_smile:

#12

Sometimes a hack is required XD. As long as I don’t get a lock while developing I am cool. I will look into it more in detail after most - all of the core features are finished before I start making content.