Is AWT in jdk 1.5_04 on FC4 tottally messed up??? Remember promise compile once, run anywhere? Well I took classes for my game lib & simple space invaders clone that works as espcted on windows xp and try to run them on fc4 as installed from original dvd, with no updates applied yet. I have ofcourse downloaded latest jdk release from sun site and am sure to run with sun's virtual machine not gcj's, as fedora cames setuped to ibm's compiler & gcj's runtime. I have never seen so many problems with java before. When starting up game my JFrame is crippled to something like 5x5 pixel big clump on the middle of the screen. After I digged into docs I found that they have reimplemented awt & swing on linux to use xlib instead of motif. ( http://java.sun.com/j2se/1.5.0/docs/guide/awt/1.5/index.html ). One can change the toolkit being used as described here: http://java.sun.com/j2se/1.5.0/docs/guide/awt/1.5/xawt.html. However with changed toolkit from xlib to motif, the game runs but is still unplayable at best. Icons are jumping around the screen & everything is freezing all the time and just plain not working at all. For example whole JFrame & input freezes for sweveral seconds, then it accepts input and animte, then it freezes again & so on ... I haven't had time nor lust to digg into reasons - if it is either something to fedora or jdk. What I wonder with this post if you others are experiencinig same problems? I never before had problems with jdk on linux, it worked just as it would. One day that comes I'll try to install jdk 1.4 on fc4 and see if problem persists, but untill I get the time, it's nice to hear if there is some clue to what might be wrong. And word about my game: it is done only on top of jdk. I don't use any extern java classes, nor native code calls from app side - just pure jdk classes. Only AWT and Swing used is just one JFrame opened for drawing onto and AWTEVent object for polling input. No other widgets at all are used. Everything else including ui is done at app level code with pure java and jdk help. I have also recompiled all classes in fedora, just in case, but no luck it's same thing.

I havent done anything with graphics but I did come across a component sizing issue using Suse. My application ran perfectly except I had to define two different sets of dimensions for the window and the objects to get them to look exactly the same on both windows and Suse.

If anything depends on something being the exact size you set it to on windows it might not be the same on linux. Just a weird thing I came across, maybe someone knows why this happens, but I have no clue.

*it could have been differences in default system font sizes or something but I didnt really go into it much to find out.

Well I setup JFrame to unresizable 600x800 frame and that's all sizes used. But using setSize(int, int) on JFrame, shouldn't be problem, it never was before. As said this is problem if I run with default (xlib) toolkit. When I switch toolkit to Motif I get up JFrame. However problem is those freezings that occur all the time.

I have also done some very simple test with only opening a JFrame and then maximizing - minimizing it. I use keyboard for doing it. However when pressing one key, I have to switch to some another window on desk, and then again back to java window, otherwise it doesn't react on keyboard input despite that window has focus. And I have to switch so for every press just to give it focus. When running on Motif toolkit, this still happends sometime, but very rearely. I guess it has something to do with awt iput thred or something there. I can post my simple example on thursday since I'm not at home at the moment.

Yup thats what I did too. I dimensioned my JFrame with setSize(int, int) and everything was strictly constrained and dimensioned with gridBagLayout. But when run on linux the components inside the JFrame still came out larger than on windows, so I had to increase certain dimensions so that all components were displayed properly. I didnt really care much though as it was mainly for windows and I wanted to see how it looked on linux. But as you said this probably has nothing to do with your game problems, just throwing out a little oddity i came across.

If you are using a BufferStrategy to handle page flipping or double buffering be sure to remember to add code to sync the display. It is a known problem with Linux. Curious if that will help. Here is some sample code:

if(frame != null)
{
buffer = frame.getBufferStrategy();
if(!buffer.contentsLost())
buffer.show();
}
//sync the screen, fixes problems on Linux
Toolkit.getDefaultToolkit().sync();