Applet main loop

Performance Tuning
#1

I know this must have been covered in various places in the past. However, I would be interested in your opinions and alternatives for the “Applet main loop” problem; How to structure the main loop of a real-time applet?

I think we all more or less agree on:


public class RealTimeApplet extends Applet implements Runnable
{
Thread thread; // Runner thread

public void start () {
thread = new Thread ( this );
}

public void stop () {
thread = null;
}

public void run ()
{
while ( thread != null )
{
// run main loop
}
}

public void update ( Graphics g )
{ // override because origional cleared screen
paint ( g );
}
}

Now comes the interesting part. How do we update logic and then repaint in the main loop. These are some ideas/approaches I’ve seen:

  1. Just grab the Applet’s Graphics context and use it however you like (bypassing the paint() function). This is not very friendly, and I’m not sure have supported it is by various AWT implementations.
  2. In the main loop, wait() after calling repaint(). The paint() function then calls notifyAll() when it is done. When running on a fast computer, the applet can eat up too many resources (ie. freeze the system by taking almost all time). This means some performance manager must be implemented to avoid this :(.
  3. Just use Thread.sleep (1L) at the end of the main loop. This is kind of a hack :(. It avoids eating too many resources though.

I would like to know what other approaches there are, because these all have some drawback(s) which I don’t like.

Also, who uses ToolKit.vsync () and where should it be used. Who uses Thread.yield () and where should it be used.

You see I have many questions ;). Sorry guys, but I’m looking to sort this out once and for all.

Thanks.
from, Stefan

#2

Applet animation is kind of a black art. The shrot answer is in the limited 1.1.x world of Applets there really isn’t a ‘right’ way to do it, those who write applet games have found all sorts of hacks to make the wrong ways function all right.

In applciations, use JDk1.4 BufferStratagey to get the graphics to paint do and do all your processing and painting in a bgi loop in a single thread (totally bypassing AWT paint() ), thats the way "real’ games have done it for a long long time in other languages.

#3

Well regarding 1.1 stuff…

I always set the thread priority to min else the applet will hog to much os time when the applet is not focus on WinNT / Win2K boxs.

And then just make empty update / paint methods and grab store a Graphics ( g_ref = this.getGraphics )reference in the applet init() method to use for drawing to the applet canvas, and when image builder store use an MemoryImageSource and newPixels the image (and if you are not using the alpha channel which is done by dither and looks ugly use a color mode that is only 24 bit ( DirectColorModel cmr_img_cm = new DirectColorModel(32,0xff0000,0xff00,0xff); ) and use that when you create the MemoryImageSource and the image gets built about 30% faster!

:slight_smile: hope that helps…