This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
C Krit
Greenhorn
Posts: 6
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1561
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Posts: 6
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 6
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Pie
    Posts: 20381
    46
    Chrome Eclipse IDE Java Windows
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    C Krit
    Greenhorn
    Posts: 6
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 1561
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 6
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thank you!
     
    I agree. Here's the link: http://aspose.com/file-tools
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic