# Swing for game development - regarding threads

For those of you who use Swing to develop their real-time Java games. (Meanign a game that constantly updates game state and redraws the screen using a constant loop).

As I see it, there are three main possible approaches to designing games in Swing, in relation to threads:

1- Have the entire game (except for especially long-running tasks) run on the EDT.

2- Have the entire game run on a non-EDT thread.

3- Have clear seperation between a thread to constantly run game logic (a non EDT thread), and a thread to constantly update the screen (the EDT).

By your experience and knowledge, which approach is the most common, and/or the most efficient, and/or the most reasonable programming-wise (aka isn't relativley very complex to design)? Which approach should I use?

Help would be appreciated :) (I really want to pick up good habits).

EDIT: Clarification - Even if you don't recommend Swing for game development, please answer my question as it is. Thank you

• What type of game are we talking about? More like Minesweeper or more like Minecraft? – Thomas Mar 15 '14 at 15:12
• @Thomas More like Minecraft. I'm talking about real-time games. – Aviv Cohn Mar 15 '14 at 15:15

I think you should forget the EDT for graphics because Java's repaint mechanism is quite convoluted and unreliable (in terms of fixed refresh rates). For instance, repaint request do not have to be executed immediately by the JVM: multiple repaint calls may get collapsed into a single paint operation. Plus, you have AWT/Swing's entire event mechanism tied to your leg that will slow things down.

Instead, I would suggest to either use a BufferStrategy (e.g. through Canvas) which uses hardware acceleration.

public class Game extends Canvas {
public void render() {
BufferStrategy bs = getBufferStrategy();
if (bs == null) {
createBufferStrategy(2);
} else {
Graphics g = bs.getDrawGraphics();

// render game

g.dispose();
bs.show(); // flip screen
}
}
}


This is certainly fine for smaller projects. Or for bigger games, consider using an OpenGL wrapper library, such as, e.g., LWJGL.

• Is it okay to still use Canvas? I thought the standard is to entierly replace it by JPanel. Pretty sure the standard is to replace all AWT by Swing except for more 'local' things (aka not the infastructure of entire applications) – Aviv Cohn Mar 15 '14 at 13:33
• Also, I understand Swing isn't optimal for game development, but if you can please do answer my question – Aviv Cohn Mar 15 '14 at 13:35
• If you mean whether Canvas is deprecated then the answer is no. Swing has a number of advantages over AWT for building desktop applications but AWT is still a fully fledged member of the Java core libraries, even in Java 8. – Thomas Mar 15 '14 at 14:55
• Also, note that there's no problem using a Canvas together with Swing component such as, e.g., a JFrame. So you could still use swing for almost everything except where performance matters. But since it is rather uncommon for games to integrate any standard GUI components (such as radio buttons, checkboxes etc.) in the first place, there's really no reason why you shouldn't use Canvas. – Thomas Mar 15 '14 at 15:00
• I see, I'll try what you're suggesting. Anyway, I'll appreciate it if you can answer my original question. – Aviv Cohn Mar 15 '14 at 15:04

If you want to use swing, you have to run it on the EDT, so option wouldn't work. As you mentioned any long-running stuff should'nt be on the EDT and any minecraft-like game would be pretty intensive so that makes option 3 the best one. Just make sure that everything in the logic thread is threadsafe and that you use invokeLater() to do anything on the render thread from the logic thread.