graphics obj during rendering

[Kommi]

I was just thinking about this in terms of garabge collection. In my rendering loop I have a
Graphics g = bs.getDrawGraphics();
and then later
g.dispose();
So each render I crate and dispose of the graphics object. Is this a proper way of rendering? Wouldn't the constant creation and disposing of the object trigger the gabage collection at a bad time?

[kevglass]

bs.getDrawGraphics() doesn't nessersaryly create a graphics object. In the same way g.dispose() doesn't mean that the graphics object would be destroyed and garbaged collected.

Kev

[D.t.O]

Is there any way to more or less label an object so that you can be sure it will be garbage collected on the next run of the garbage collector?

Games published by our own members! Check 'em out!

[Jeff]

Absolutely not.

GC is always at the dsicretion of the VM. It has to be to allow for efficient gc algortihyms.

[D.t.O]

dang. oh well.

Thanks for the info though.

[cfmdobbie]

If the object is short-lived, the VM will notice and make special considerations for it.  You shouldn't get any GC pause from short-lived objects with a modern VM.

When starting programming in Java, the first rule of memory management is just not to think about it - a number of very intelligent engineers have designed the VM such that you shouldn't have to.

[trembovetski]

A note: a Graphics object is a graphics context and is pretty lightweight as such, it just holds a state.

It's better to obtain a new graphics context every time, and then dispose of it.

[D.t.O]

When you call foo.getDrawGraphics() twice, do you get two separately allocated Graphics objects, or just one object that is returned twice? Is this behavior constant, i.e. do you always get the same behavior?

[Jeff]

Unless it says soemthing specific in the Java doc that woudl be VM dependant.

Anything not in the JavaDocs is VM dependant by definition

[D.t.O]

I edited my post while you were writing, but I guess you answered the second question too
Thanks