If you read the documentation of repaint
carefully, you will notice that it states that (emphasis mine):
If this component is a lightweight component, this method causes a
call to this component's paint method as soon as possible. Otherwise,
this method causes a call to this component's update method as soon as
possible.
This means that AWT/Swing is allowed to optimize repainting by merging repaints that are requested in a rapid succession. There is also a repaint(long time)
method, which allows you to control how long AWT/Swing is allowed to wait with fullfilling your repaint request. It might still merge requests though, especially if you do them in a loop.
It might be helpful to read the article "Painting in AWT and Swing", which tries to explain the various concepts involved.
To get the panel repainted for every iteration, you would have to wait for a paint to happen and then proceed with your loop. This means you need some synchronization between your processing thread (the loop) and the AWT/Swing thread. As a rough idea, you could for example wait()
on the panel object at the end of your loop if it has not been repainted since the last call to repaint()
and call notifyAll()
at the end of your panel's paintComponent()
method. However, this can be tricky to implement right, so you should only do this if you really need "real-time" redrawing of your component. As an alternative, paintImmediately(...)
could be used, but you would have to do all your processing in the event dispatching thread, like this:
SwingUtilities.invokeLater(new Runnable() {
public void run() {
while(notDone) {
// Do your processing
panel.paintImmediately(...);
}
}
});
Note that this will stop any event processing including mouse and keyboard input from being processed while your loop is running. You can read more about Swing and Threading in "Concurrency in Swing"
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…