File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Swing / AWT / SWT and the fly likes Game of life implementation - facing swing freezing problems [solved] Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Game of life implementation - facing swing freezing problems [solved]" Watch "Game of life implementation - facing swing freezing problems [solved]" New topic
Author

Game of life implementation - facing swing freezing problems [solved]

C Krit
Greenhorn

Joined: Jan 05, 2009
Posts: 6
I'm in need of help again and back to Javaranch ("forgotten password" doesn't seem to work:/), so hello all, again!

I'm implementing Conway's Game of life, in java. It works, and I'm at the stage of trying to make a simple interface to allow control of the speed, grid size etc. The first control that I created is the start/stop button and I'm having trouble with starting and stopping the simulation.

This is my method that calls each step of the game:


This works just fine as soon as the program is run. It works with different settings well. The problem arises when I try to pause the whole thing. If i set the stop boolean to true, then false and call start() again, the gui gets stuck at the paused state and becomes unresponsive (I need to force quit). All that the gui.update() does, is call the Graphic component's repaint() method.
Note that the simulation still runs well, except for the GUI. grid.update() calculates the next step correctly and on time, and this is reflected when grid.print() prints the output in the commandline correctly (in the meantime the gui gets stuck).

I think I've supplied with enough info, I'm more than eager to supply more if needed!
pete stein
Bartender

Joined: Feb 23, 2007
Posts: 1561
Without seeing more of your code, it's hard to say, but as a guess, are you taking care that you are not pausing or sleeping the Event Dispatch Thread (EDT)? In other words:

  • are there any CPU or time-intensive processes that should be in background threads that are run on the EDT? If so, look into using a SwingWorker.
  • are you calling Thread.sleep(...) in the EDT? If so, don't do this. Do this on a background thread, or use a Swing Timer or SwingWorker.
  • are you using a while loop to act as "game-loop" mechanism? If so, use a Swing Timer instead.


  • your wait(t) method has me worried. I'll bet that you'd do well to do your processing in a background thread such as a SwingWorker and use a Swing Timer (both!) to time the whole animation, but YMMV.

    You may benefit by searching and reading up on "concurrency and Swing". Best of luck.
    C Krit
    Greenhorn

    Joined: Jan 05, 2009
    Posts: 6
    Right, seems like I need to study a bit more then! I'll post again when I do know what the terms you said mean!
    My wait method is:

    C Krit
    Greenhorn

    Joined: Jan 05, 2009
    Posts: 6
    I've solved it by using a swing timer. Thanks Pete for your precious help! Just for the record here is my code:


    If anyone has the time i'd please like to know why the Thread.sleep() messed the gui stuff up initially!
    Once again, thanks Pete!
    Rob Spoor
    Sheriff

    Joined: Oct 27, 2005
    Posts: 19655
        
      18

    Because it was executed in the Event Dispatcher Thread. This is the one single thread that is both handling all events, as well as all repainting. So when you're letting that thread sleep, it can't do anything else - no event handling, no repainting, nothing.

    See http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html for more info.


    SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
    How To Ask Questions How To Answer Questions
    C Krit
    Greenhorn

    Joined: Jan 05, 2009
    Posts: 6
    Rob Prime wrote:Because it was executed in the Event Dispatcher Thread. This is the one single thread that is both handling all events, as well as all repainting. So when you're letting that thread sleep, it can't do anything else - no event handling, no repainting, nothing.

    See http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html for more info.

    I get it...but why did the rest of the program continue to function well, even if the EDT was sleeping? Is only swing dependent on the EDT?
    pete stein
    Bartender

    Joined: Feb 23, 2007
    Posts: 1561
    The EDT is where Swing does its drawing and where it processes user interactions (button clicks, mouse events, keyboard events, etc...). When it is tied up, these functions, which require quite a bit of processing power, just don't work or only partially work even though the rest of the program may be working fine.

    C Krit wrote:I get it...but why did the rest of the program continue to function well, even if the EDT was sleeping? Is only swing dependent on the EDT?
    C Krit
    Greenhorn

    Joined: Jan 05, 2009
    Posts: 6
    Thank you!
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Game of life implementation - facing swing freezing problems [solved]
     
    Similar Threads
    Questions regarding to using applets and JComponents
    need a thread
    Java Problem
    Threads and calling methods on it explicitly
    Buttons not displaying till I mouseover them?