AWT fast graphics & thread safety

Question

I'm porting a really old AWT game to a really naff new device.

The game has a whole bunch of things wrong with it, including a very lax approach to thread safety: the game engine is trying to draw directly onto the screen in its engine thread using a graphics context it got from the UI thread. This doesn't work on the device.

I've managed to hack it into working, by having the engine thread draw onto an off-screen buffer and then have the UI thread periodically call repaint() on the display component and the display component blitting the buffer onto the screen, but performance sucks --- not surprising given all the context switches and double buffering.

I'm not actually a particularly knowlegable AWT programmer; it's sufficiently hateful that I've avoided it up to now. But this problem --- having an engine thread want to draw onto the screen --- must be a common one. Does anyone know of any decent strategies (and preferably example code!) of how to do this in a safe manner that squeezes as much performance out of the system as possible?

(What I'd particularly like is a safe shortcut to allow the engine thread to directly render onto the screen graphics context when it feels ready to do so, and so avoid having to tell the UI thread to request a redraw. That will let me take out a whole layer of double-buffering. But I don't know whether such a thing is possible...)

This is all on PBP 1.1.2 --- yes, it's neither full Java nor honest MidP...

Answer 1

Using a game canvas might help. It allows the painting to be done in the game loop, so you wont need double buffering. Another more crude approach is to use paintImmediately(). It will force the gui to repaint.

//Gui
public void update(/*may want to pass the shapes to paint*/)
{
    paintImmediately(this.getGrphics());    // assuming 'this' is a jpanel
}


//Game loop
public void gameLoop()
{
    // collision detection etc
    gui.update();
}