Kevin Weiner <[EMAIL PROTECTED]> wrote:
>You should override update to only invoke paint; otherwise, it
>will always clear the background first. Then just move all your
>drawing code to paint (you could put it all in update, but paint
>is more standard).
>
Actually, in Swing, all update does is call paint (take a look at the source
code in JComponent). The correct way to avoid clearing the background is to
override paintComponent without calling super.paintComponent(g).
However, in this case, we do want to clear the background each time the
animation updates. I think Tim's problem is something else. His sample
code shows his simulation thread doing two things:
1) The simulation loop draws a shape into the Graphics of his Swing object
every time one of the simulated objects moves.
2) After all objects have been moved, the simulation loop calls repaint() on
the Swing object, causing the background to clear when the Swing event
thread gets around to refreshing the screen.
The flicker is caused by clearing the background independently from drawing
the simulated objects. In this case, it is especially bad because the
clearing is done on a different thread than the drawing, so it may happen at
a random time in the simulation cycle.
I believe that the following is the simplest approach:
1) Remove the drawing code from the simulation loop - it should adjust the
simulated objects and call repaint(), letting the Swing paint mechanism take
care of the redraw.
2) Do all drawing in the paintComponent method (including the call to
super.paintComponent to clear the background)
No special concern for double buffering is needed, because Swing does this
by default.
I have sample code that I'm sending to Tim off-list.
Andy
===========================================================================
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".
