Any final verdict on if we should request a new Graphics object once per game loop (and dispose it once per game loop) vs. just obtaining one at application start-up?
fact: when a window is minimized (in RedHat5, on my bro’s computer at work), Graphics will return null until it is once again visible on the screen. I’m not sure if redhat is destroying the window or what, that’d seem dumb, but it is redhat. :\
fact: oNyx says he held a Graphics for an entire game session and it ate up RAM on a Mac
this shows you can’t just trust the java implementation you’re working with. I think this is why the javadoc adds “when a component is not displayable.” different OSs handle windows differently, it seems. though I can’t imagine why redhat would destroy a freakin window, and recreate it from scratch when it is maximized… I’ll have to try some more redhat versions to see if they bothered to change that o_O
edit: just because I was curious, in Redhat5 I also tried holding onto the Graphics the entire time (since getGraphics() would return null when iconified), and after the window minimized, the VM crashed (without the hs_err_* file thing). 
I see. Well then I better create a new Graphics object once per game loop and check for null. But, it’s probably okay to hold onto a Graphics object created from a BufferedImage as the visibility rules don’t apply to it.
from a 4K standpoint, I’d say “f**k it” and do what you want, since most of it is hackery anyway, and most people are using Windows to run the games (as far as I know)
as far as I know, but then again if the user is on a mac, they might have the RAM consumption problem oNyx had
edit:
moral of the story is this. while you develop you game, post it here so we can all test it and give you suggestions and such. Graphics is one of the easier problems to deal with, there are tons of other things that can happen. so, post at this forum, and we’ll all test 