public void update(Graphics g) {
// Background: map field
g.drawImage(backbuffer, 0, 0, this);
// Foreground: headsup display
headsup.draw(g);
}
public void paint(Graphics g) {
update(g);
}
Now the problem is that even though the window (Firefox or
AppletViewer) is left unresized and nothing obscures it, the
update-method gets called repeatedly without-end, giving
less-than-optimal performance, and a lot of flickering.
Are you calling repaint() from anywhere other than your frame update?
Note that using "this" as the last parameter of g.drawImage() can lead to
calls to repaint() since the default implementation of the ImageObserver in
Component executes a call to repaint whenever more of the image is loaded
from its source. However, this only happens for images loaded from a file
or network connection, not images created with "createImage(w, h)" or "new
BufferedImage()" (basically any image that you can render into which
eliminates backbuffers) since those images are not loaded from a source
image stream.
Even more strangely, when starting the Applet, it works fine (update()
gets called once a second..) for a some 5-10 seconds, then the mad
update()-calling begins. I'm under WinXP, JRE1.4.2. The continuous
update:ing really hogs the CPU (gets up to 90%) which is not good for
a game supposed to be run on a web page while the user listens to
music for example.
Have you tried it with 1.5? Or one of the pre-release builds of 1.6?
What happens right before the trigger? You could try overriding repaint()
to see where it is coming from, but it is hard to get that information back
out of the applet. You could see if the calls are going to paint() or
update() by doing something like:
update(Graphics g) {
render(g, Color.blue);
}
paint(Graphics g) {
render(g, Color.red);
}
render(Graphics g, Color trackcolor) {
// the code from your current update() method
// followed by:
g.setColor(trackcolor);
g.fillRect(0, 0, 10, 10);
}
Depending on the color of the square in the upper left you would know if
this was the result of a call to update() (which means it came from a call
to repaint() at some point) or if it was a call directly to paint() (which
means it was handling some perceived "damage" to the window)...
...jim
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
