setVisible()-Aufrufe werden zu spät umgesetzt

[Tissi]

Hallo!

Ich hab folgendes Problem:
Es geht um ein kleines Quizspiel und am Ende sollen die Spieler nach Punkten sortiert werden und, mit dem letzten Platz beginnend, nacheinander angezeigt werden. Dazu folgende Methode:

	public void evaluate() {
		this.btn_evaluate.setVisible(false);
		this.pnl_questionoverview.setVisible(false);
		this.game.evaluate(); // beendet das Spiel und sortiert die Spieler
		this.pnl_players.setVisible(false);
		this.pnl_evaluation.setVisible(true);
		this.pnl_evaluation.showEvaluation(this.game.getPlayers());
		this.btn_exit.setVisible(true);
	}

	public void showEvaluation(Player[] players) {
		for (int i = 0; i < this.lbls_place.length; i++) {
			this.lbls_place[i].setVisible(false);
		}
		
		int place = 0;
		for (int i = 0; i < players.length; i++) {
			if (i == 0 || players[i].getScore() < players[i-1].getScore()) {
				place++;
			}
			this.lbls_place[i].setText(place + ". " + players[i].getName() + " (" + players[i].getScore() + ")");
		}
		
		final int timeout = 1000;
		long time = System.currentTimeMillis();
		while (System.currentTimeMillis() - timeout < time);
		for (int i = players.length - 1; i >= 0; i--) {
			this.lbls_place[i].setVisible(true);
			if (i > 0 && players[i].getScore() < players[i-1].getScore()) {
				time = System.currentTimeMillis();
				while (System.currentTimeMillis() - timeout < time);
			}
		}
	}

Jetzt folgendes Problem:
Die ersten vier setVisible()-Aufrufe in evaluate() sind nicht sofort auf dem Bildschirm sichtbar. Erst nachdem showEvaluation() durch ist, werden die Komponenten ein- bzw. ausgeblendet. Dadurch ist mit einigen Sekunden Verzögerung (aus showEvaluation()) die gesamte Auswertung auf einmal zu sehen.

Meine Frage also: Warum??? Ich verstehs einfach nicht.

 

[hdi]

[HIGHLIGHT="Java"]public void showEvaluation(Player[] players) {
SwingUtilities.invokeLater(new Runnable(){
@Override
public void run(){
// der eigentliche Code dieser Methode
}
}
}[/HIGHLIGHT]

Im Übrigen nennt man das hier:

[HIGHLIGHT="Java"]while (System.currentTimeMillis() - timeout < time);[/HIGHLIGHT]

"Busy Waiting", und das zieht deine CPU auf 100%. Ersetze diese Schleife einfach durch:

[HIGHLIGHT="Java"]Thread.sleep(timeout);[/HIGHLIGHT]

 

[Tissi]

Erstmal vielen Dank für die superschnelle Hilfe. Damit funktioniert's.

Leider ist mir immernoch nicht klar, warum mein Code nicht funktioniert hat. Merkt sich da irgendein Objekt die repaint-Anweisungen zwischendurch und führt nachher alle zusammen aus oder was passiert da?

 

[hdi]

Naja das Problem liegt darin dass Java alle Swing-Events in einem sog. "Event Dispatch Thread" behandelt. Also zB läuft jedes repaint() darauf.
Dieser EDT verstehst sich nich so gut mit anderen Threads.

Der Code in meinem Bsp erstellt einen neuen Thread, und legt diesen Thread in eine Warteschlange, die genau dieser EDT abarbeitet.
D.h. jetzt bearbeitet der EDT die Methode, und damit kann er auch mit dem repaint()
ordentlich umgehen.

Das geht eben (meistens) nicht einfach so.

Generell kannste dir merken: Wenn du irgendwo Berechnungen durchführst, und gleichzeitig etwas mit Swing-Komponenten tust (zB repaint()), sollten diese Berechnungen auf den EDT gelegt werden.

 

[Ebenius]

Naja das Problem liegt darin dass Java alle Swing-Events in einem sog. "Event Dispatch Thread" behandelt. Also zB läuft jedes repaint() darauf.
Dieser EDT verstehst sich nich so gut mit anderen Threads.

[...]

Generell kannste dir merken: Wenn du irgendwo Berechnungen durchführst, und gleichzeitig etwas mit Swing-Komponenten tust (zB repaint()), sollten diese Berechnungen auf den EDT gelegt werden.

Aua. Das ist so ziemlich gesamtheitlich verkehrt. Das von Dir beschriebene wäre ja Voodoo...

• repaint() ist eine Methode; sie läuft natürlich in dem Thread der sie aufruft.
• repaint() ist explizit dafür da, in jedem Thread aufrufbar zu sein.
• repaint() zeichnet eine Komponente nicht neu, sondern legt einen PaintEvent in die EventQueue! (vereinfacht dargestellt. RepaintManager und dirtyRegions interessieren jetzt mal einfach nicht)
• Der EDT macht nix anderes als die EventQueue zu pollen und -- wenn Events drin liegen -- alle Events in der selben Reihenfolge abzuarbeiten in der sie in die Queue geworfen wurden (Klar. Queue sagt das schon: FIFO).
• Berechnungen -- sofern sie nicht trivial sind -- werden explizit in einem anderen Thread gemacht; macht man sie im EDT (also zum Beispiel in der actionPerformed(...)-Methode eines ActionListeners) hängt während der Berechnung die GUI mit allen Konsequenzen (kein zeichnen beim Fenster vergrößern / verkleinern; der Progress-Bar updated sich nicht; und all der Rest eben).
• Veränderungen an AWT-/Swing-Komponenten muss man aber synchron zum EDT machen. Das bedeutet: Die längere Berechnung macht man in einem separaten Thread (gut geeignet immer die SwingWorker-Klasse) und die Veränderungen der GUI lässt man dann im EDT machen. Entweder über die done()-Methode des SwingWorkers oder über SwingUtilities.invokeLater(...) oder SwingUtilities.invokeAndWait(...) (letztere Methode sehr selten).

Ebenius

 

[hdi]

repaint() zeichnet eine Komponente nicht neu, sondern legt einen PaintEvent in die EventQueue!

Ja, das entkräftet doch irgendwie die anderen beiden Aussagen, die du über repaint() machst. Also, ist schon korrekt, aber wenn ich sage repaint() läuft auf dem EDT, dann stimmt das doch, oder? Egal vonwelchem Thread ich das aufrufe. Also...mir repaint mein ich das Malen an sich, also ich meine davon redet man, wenn man sagt "ich mach repaint". Man will, dass gezeichnet wird, egal "wer" das jetzt tut.

Der EDT macht nix anderes als die EventQueue zu pollen und -- wenn Events drin liegen -- alle Events in der selben Reihenfolge abzuarbeiten in der sie in die Queue geworfen wurden (Klar. Queue sagt das schon: FIFO).

Jo, ich glaub darüber hab ich nix gegenteiliges gesagt, oder überhaupt was gesagt

Berechnungen -- sofern sie nicht trivial sind -- werden explizit in einem anderen Thread gemacht

Stimmt, eigentlich weiss ich das auch. Hatte wohl irgendwie nicht nachgedacht vorhin als ich das geschrieben habe, bzw. was anderes gedacht als geschrieben. Ich meinte nur man soll das trennen, also Swing-Sachen auf die EventQueue legen. War natürlich total falsch wie ich es geschrieben hab, da hast du vollkommen Recht

SwingUtilities.invokeLater(...) oder SwingUtilities.invokeAndWait(...) (letztere Methode sehr selten).

Ich glaub ich hab das schon 3 mal gefragt, falls mir das jemals jmd schon gesagt hat, entschuldige. Aber was ist genau der Unterschied zwischen den 2 Methoden?

 

[Ebenius]

Ja, das entkräftet doch irgendwie die anderen beiden Aussagen, die du über repaint() machst. Also, ist schon korrekt, aber wenn ich sage repaint() läuft auf dem EDT, dann stimmt das doch, oder? Egal vonwelchem Thread ich das aufrufe. Also...mir repaint mein ich das Malen an sich, also ich meine davon redet man, wenn man sagt "ich mach repaint". Man will, dass gezeichnet wird, egal "wer" das jetzt tut.

Da Du "repaint()" mit Klammern geschrieben hast, bleibt dem Leser doch nix anderes übrig als zu glauben, Du meintest die Methode.

Ich glaub ich hab das schon 3 mal gefragt, falls mir das jemals jmd schon gesagt hat, entschuldige. Aber was ist genau der Unterschied zwischen den 2 Methoden?

invokeLater(...) ist wie Brief wegschicken. Brief ist raus, weiter gehts. invokeAndWait(...) geht nur von außerhalb des EDT (sonst gibt's ne Exception). Ist wie Einschreiben mit Rückantwort. Vor der Rückantwort geht's nicht weiter. Anders gesagt: Der Methodenaufruf kehrt erst zurück, wenn der EDT den Auftrag erledigt hat (also nachdem die run()-Methode des übergebenen Runnables fertig ist).

Ebenius