Originally Posted by nemo
Because you don't know what state the Graphics component is in, and accessing it from a different thread (eg the main thread as opposed the EDT thread) makes matters much worse. Things like window resizes, events, and/or layouts can change the graphics object. Meaning it can get wiped out, transformed, or worse set to null while you are trying to access it, resulting in unexpected behavior. And when I say unexpected I mean unexpected - it may work now but down the line you never know. Using paintComponent ensures you will paint to a Graphics object with the expected behavior.
i had it working using paintComponent, but it was at least 5 times slower than using a buffer. plus, if i need to, i can using a SwingTimer to control the painting of the screen manually.
If its that much slower that it is noticeable to a human, you should profile the code and fix the bottleneck. Things you are doing should be lightning fast, and if they are not there are always ways to fix it and speed it up.
basically, what's the advantage of an EDT over manually creating a buffer?
No unexpected behavior I mentioned above, Listeners (ActionListener, MousetListener, KeyListener, etc...) already managed for you, more assurance the code is portable..are just a few. And you aren't manually creating a buffer, you are retrieving the one created for you by Swing in the EDT.
and lastly, can anyone answer my original question, how to use XORMode when dealing with moving sprites?
I haven't played with this option for some time, so shouldn't lead you astray with my assumptions.