Greetings all!
First post here on JGO. Looking forward to learning and contributing ;D
I am using a Canvas within a JFrame and was wondering, should I be using a Frame instead of a JFrame? Also, should the creation and showing of either (Frame/JFrame) be done on the EDT thread?
Thanks!
If you are only use Canvas, then stick with Frame. No need to initialize the entire Swing mess.
And yes, that is preferable. 
Ok, Frame it is then. Thanks Ra4king
I want to ask a dumb question… what’s the advantage of using Frame and Canvas instead of, say, JFrame and JPanel or JComponent?
Kinda outdated article here: http://www.ibm.com/developerworks/grid/library/os-swingswt/
What I picked up was just that they’re thread-safe and are (mostly) automatically disposed of.
ばかなしつもんがない。
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.
http://docs.oracle.com/javase/tutorial/uiswing/components/index.html
google-fu:
http://www.jguru.com/faq/view.jsp?EID=232717
http://www.dreamincode.net/forums/topic/185591-canvas-v-jpanel/
Thanks. From that article:
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.
Because Canvas is less of a pain to use.
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 );
Can I ask how? I’m not trying to be argumentative or disagree, I just honestly can’t see how Canvas is easier than JPanel or JComponent.
[quote=“jonjava,post:9,topic:41032”]
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.
Thanks, that makes perfect sense.
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.
Thanks again for taking the time to answer my dumb questions!
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.
Throw Canvas away if you’re using some better other libraries. Moreover, IIRC, JOGL could directly draw java Canvasies.
Also, learning to deal with your own double buffering is both a trivial but useful thing that might get lost in Swings mysterious world.
IMO :V