再描画は、再描画の呼び出しではなく、再描画するための Swing への要求です。カバーの下で repaint() は、再描画ジョブをイベントのキューに投稿しています。その再描画ジョブに加えて、マウスの移動、マウスのクリック、キーボードのアクティビティなどもそこに投稿されます。Swing スレッドがやって来て、定期的にそのキューからジョブを実行し、UI を再描画したり、マウスやキーボードのイベントをコンポーネントに配信したりします。実際、swing スレッドはこれらのイベントを頻繁に配信しますが、UI が実行している作業量に依存します。そのSwingスレッドで。マウス クリック、キーボード イベント、および再描画を配信しているときは、そのキューから読み取ることができません。そのため、コードがイベントに応答するのに長い時間がかかる場合、swing が新しいイベントにタイムリーに応答する能力が低下するか、すべてがブロックされます。
そのため、Swing イベント ディスパッチ スレッドを使用してネットワーク経由でブロッキング サービス コールを実行すると、そのコールが戻るまで UI の描画が停止します。これが、ネットワーク呼び出しなどの長時間実行されるジョブを Swing スレッドから移動し、呼び出しが戻ってきたときに SwingUtilities.invokeLater() を使用して、イベント スレッドで UI を更新できるようにすることが重要である理由です。(invokeLater() は、上記で説明した Swing イベント キューにジョブをポストすることでこれを行います)。
これが、Swing イベント スレッドで sleep を呼び出すのがひどい考えである理由でもあります。そのスレッドをスリープ状態にすると、キューからイベントを処理できなくなります。また、リクエストした repaint() は、Swing スレッドがスリープしている間は実行されません。
まず、スリープ コールを削除します。2番。追加のロジックを実行する前にペイントを終了することに依存するコードを記述しないでください。再描画と再検証は特別な呼び出しであり、Swing は再描画/再検証の要求を組み合わせて、10 回連続して再描画しないようにします (重要な CPU 時間を浪費します)。
Swing は、呼び出し元のスレッドが最初に呼び出したメソッドから離れるまで、パネルを再描画できません。スレッドがそのメソッドを離れるのが早ければ早いほど、 repaint() が早く発生します。
再描画をすぐに実行したい理由を説明していないので、気にしないようにコードを構造化する方法についてアドバイスすることはできません。しかし、再描画がまだ行われていないことを気にする必要はありません。