在 Java、AWT 中，重绘方法似乎被忽略，而有利于启动方法
我正在构建一个棋盘游戏小程序，处理用户输入大致如下所示：
public void mousePressed(MouseEvent event) {
int row = event.getX() / (getSize().width / 8) ;
int column = event.getY() / (getSize().height / 8) ;
if(possibleMove(column, row) {
makeMove(column,row,whosTurn);
repaint();
start();
}
}
在人工输入后，计算机选择一个动作并像此方法一样调用 repaint() 和 start() 。
但屏幕似乎只有在计算机移动后才会更新，因此在调用 start() 之后。既然 repaint() 在 start() 之前调用，怎么会发生这种情况呢？
我怀疑这可能是因为 repaint() 启动了一个新线程（是吗？），但为什么它会等待 start() ？
当然，如果有必要，我可以提供更多代码。
I'm building an applet of a board game, and handling user input roughly looks like this:
public void mousePressed(MouseEvent event) {
int row = event.getX() / (getSize().width / 8) ;
int column = event.getY() / (getSize().height / 8) ;
if(possibleMove(column, row) {
makeMove(column,row,whosTurn);
repaint();
start();
}
}
After a human input, the computer chooses a move and calls repaint() and start() like this method does.
But the screen seems to update only after the computer has made a move, so after start() is called. How can this happen, since repaint() is called before start()?
I have a suspicion this might be because repaint() launches a new thread (does it?), but why would it wait for start()?
I could provide more code if necessary, of course.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
repaint() 调用不会执行重绘 - 它会安排要完成的重绘。实际的重绘稍后由事件线程在任何当前和已计划的事件完成后执行（由于其他与此处不相关的原因，甚至可能会晚于该事件发生）。 start() 方法在调度完成后立即调用，作为响应当前事件的一部分。所以是的，实际的绘制总是在调用 start() 之后发生。
请参阅 repaint() 的说明 和绘制机制的描述了解更多详情。
一般来说，像这样调用 start() 可能是不好的。当调用 start() 时，UI 无法响应任何事情（例如调整游戏窗口大小或未覆盖），除非 start() 是一个非常短的操作，否则这将导致 UI 看起来没有响应。
The repaint() call does not do the repaint - it schedules a repaint to be done. The actual repaint is carried out later by the event thread after any current and already scheduled events have been finished (it may happen even later than that for other reasons not relevant here). The start() method is called immediately after the scheduling is done, as part of responding to the current event. So yes, the actual paint will always take place after start() is called.
See the description of repaint() and the description of the paint mechanism for more details.
In general calling start() like this is probably bad. While start() is being called the UI cannot respond to anything (such as the game window being resized or uncovered), and unless start() is a very short action this will result in the UI seeming unresponsive.
@DJClayworth 已经解释了为什么您的应用程序的行为如此，但如果您正在使用
JComponent并且您绝对需要在自己的事件处理期间进行重新绘制，您可以使用JComponent.paintImmediately()方法。但是，您可能应该首先花一些时间决定是否可以重构代码以使start()功能在事件分派线程之外发生。@DJClayworth has already explained why your app behaves as it does, but if you're working with a
JComponentand you absolutely need repainting to happen during your own event handling, you can use one of theJComponent.paintImmediately()methods. However, you should probably spend some time first deciding whether you can refactor your code to have thestart()functionality happen outside of the event dispatch thread.