Frame and Canvas are part of AWT and JFrame and JPanel are part of Swing.

AWT has been in java since 1.0 and Swing came in at 1.1 or something.

Swing has lots of built-in stuff to handle common GUI (Graphical User Interface) elements such as buttons, window bars, radio selectors, drop down selectors, input boxes for keyboard, text displaying field (proper interactive ones you can either type in, copy and paste text in etc) etc.

Simple AWT doesn't have these features, it just draws things (pixels) on screen. Swing is built on top of AWT.

So if you are doing your own drawing in the game, for example, there's no need to use Swing. You can use AWT in Swing so you can simply add a Canvas in your Swing application as a component.

Unlike AWT, Swing components are not thread-safe, which means you need to be concerned as to which thread in your application updates the GUI. If you err in thread use, unpredictable behavior, including user interface glitches, can occur. Utility routines exist to help manage threading issues.

So I see what you're saying with AWT being thread-safe (which I did not know, interesting), but not the automatic disposal (because Swing also does the same thing). Am I missing something?

I've seen plenty of gaming folks using Canvas and Frame/Applet instead of JPanel and JFrame/JApplet, and I've never quite understood why. Is the thread-safe thing (which is solved with Swing.invokeLater() and probably doesn't matter with most games anyway) really worth sacrificing all the other benefits of Swing? In gui development, AWT is almost never used over Swing, so I'm curious about why it's backwards in game development.

Thanks jonjava. I understand the difference between AWT and Swing; in fact my full-time day job is gui development in Swing. That's actually part of my confusion- The only time I see AWT actually used is in really old tutorials or in game development; everywhere else recommends Swing over AWT because of all the features, the built-in double buffering, etc.

I see your point that Swing might not be necessary for many games, which don't require "real" guis. But it still seems strange to see people recommending AWT over Swing.. it's not like you have to use the parts of Swing you don't need.

I don't mean to hijack the thread, but this is something that always itches at me.

It's like there's a shop 20m from your house. Suddenly you get a craving for cookies so you decide to go to the store. You can choose to take the car or you can walk over to the store. Taking the car most likely take more time than simply walking straight over.

On a rainy day you might avoid some rain by taking the car, but if you walk you can avoid it completely by having an umbrella.

This analogy is horrible, but whatever. :V

Basically, it doesn't make sense to botch up the game screen AND the ui / hud into the same screen. Separate them instead. And for a simple game screen Canvas is easy and flexible. Adding your Canvas into a Swing app is as simple as addComponent( canvas );

Basically, it doesn't make sense to botch up the game screen AND the ui / hud into the same screen. Separate them instead. And for a simple game screen Canvas is easy and flexible. Adding your Canvas into a Swing app is as simple as addComponent( canvas );

You can call add(JPanel) or add(JComponent) just as easily though, can't you?

I wouldn't suggest putting the ui and the game inside the same component. Instead, extend JPanel or JComponent (exactly like you do with Canvas), then override paintComponent() and you get double buffering for free. Then use a completely different JPanel for your ui (buttons, checkboxes, whatever), probably again exactly like you'd do with Canvas. This is my standard way of mocking up a game, and I don't see how Canvas makes that easier.

I feel like I'm missing something obvious, but I can't see what it is.

You're right that there's no effective "real-world" difference. The main reason I think people suggest to use AWT over Swing for games is that there's simply less overhead. As soon as you create a JFrame, a JPanel, etc., Swing's LookAndFeel-related classes all get loaded, but if you're not using any JComponents other than say a custom-painted JPanel, you don't actually use them. Why load classes you don't need or use? etc.

Again, this is a negligible "benefit", and certainly isn't noticed by users.

I would personally think that getting newbies into the habit of using AWT over Swing can lead to bad practices when they branch out to gui design, which is worse in the long run than any look and feel overhead. But that's a personal preference, and I can see the other side as well.

GUI's and games are completely different things. No need to confuse the two. There's essentially no added functionality by using JPanel over Swing. You're just "limiting" yourself to Swing.

The only thing we really need is the collection of pixels that represent the game screen. But Canvas is a good compromise since it fits neatly in both AWT and Swing. That is if you're sticking to pure java.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org