I've done the same for every game I've made, the only time I heard of the bug is from oNyx/kevglass. have you tested all your games on a mac? (I know I haven't, heh)


yes, that's what I've said like 5 times in this thread. so if you create a Graphics on each frame, you should dispose of it since the next frame is going to create yet another one, and so on, and so forth..

So, is the final verdict to ignore the possibility that getGraphics() can return null, to create the Graphics objects only once on application start-up and to never dispose them?  That works for me even under OS X.  I never tried createBufferStrategy() though.

Component.getGraphics()

"Creates a graphics context for this component. This method will return null if this component is currently not displayable."

Component.isDisplayable()

"... A component is made displayable either when it is added to a displayable containment hierarchy or when its containment hierarchy is made displayable. A containment hierarchy is made displayable when its ancestor window is either packed or made visible.....A containment hierarchy is made undisplayable when its ancestor window is disposed."

Component.setVisible(boolean)

"Shows or hides this component depending on the value of parameter b."

Window.dispose()

"Releases all of the native screen resources used by this Window, its subcomponents, and all of its owned children. That is, the resources for these Components will be destroyed, any memory they consume will be returned to the OS, and they will be marked as undisplayable."



Ergo, getGraphics() when invoked on a Window / Frame that has had setVisible(true) / show() called on it will never return null, until dispose() is called on the Window / Frame.

What is with all this talk of ultra-defensive programming!
We're talking about 4K games here 

Does pack(), without a prior call to setVisible(true), make a JFrame "displayable"?

[edit] Nevermind.  I see above that pack() is sufficient.

[2nd edit] So, we don't need to check for null, but do we need to call getGraphics() once per game loop?

I wouldn't bother checking for null either, for exactly the reasons abuse posted above.

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). :/

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