Malen in AWT und Swing - Versionsgeschichte

L-ectron-X am 22. Dezember 2018 um 10:23 Uhr

2018-12-22T10:23:23Z

← Nächstältere Version		Version vom 22. Dezember 2018, 10:23 Uhr
Zeile 377:		Zeile 377:
	Um die beste Leistung von diesen APIs zu erhalten, müssen Anwendungsprogramme die Verantwortung dafür übernehmen, die in diesem Dokument umrissenen Richtlinien zu befolgen.		Um die beste Leistung von diesen APIs zu erhalten, müssen Anwendungsprogramme die Verantwortung dafür übernehmen, die in diesem Dokument umrissenen Richtlinien zu befolgen.

	[[Kategorie:~~Java~~]]		[[Kategorie:AWT]]
			[[Kategorie:Swing]]
	[[Kategorie:Tutorials (Java)]]		[[Kategorie:Tutorials (Java)]]
	~~[[Kategorie:Swing]]~~

L-ectron-X am 1. Juni 2018 um 16:22 Uhr

2018-06-01T16:22:17Z

Änderungen zeigen

AndreUhres: /* Malen in AWT und Swing */

2013-01-12T06:34:19Z

Malen in AWT und Swing

← Nächstältere Version		Version vom 12. Januar 2013, 06:34 Uhr
Zeile 5:		Zeile 5:
	Von Amy Fowler.		Von Amy Fowler.

	[http://~~java~~.~~sun~~.com/~~products~~/~~jfc/tsc/articles~~/painting/ Copyright 1994-2008 Sun Microsystems, Inc.]		[http://www.oracle.com/technetwork/java/painting-140037.html Copyright 1994-2008 Sun Microsystems, Inc.]

	Übersetzung: André Uhres (Ich habe bei Sun die Erlaubnis angefragt, diesen Artikel zu übersetzen und hier zu veröffentlichen)		Übersetzung: André Uhres (Ich habe bei Sun die Erlaubnis angefragt, diesen Artikel zu übersetzen und hier zu veröffentlichen)

AndreUhres: /* Malen in AWT und Swing */

2013-01-12T06:31:16Z

Malen in AWT und Swing

← Nächstältere Version		Version vom 12. Januar 2013, 06:31 Uhr
Zeile 15:		Zeile 15:
	Aber die [[API]]s, die ihn verwirklichen, werden von manchen [[Entwickler]]n nicht gut verstanden -- ein Problem, das zu Programmen geführt hat, die nicht so leistungsfähig sind, wie sie sein könnten.		Aber die [[API]]s, die ihn verwirklichen, werden von manchen [[Entwickler]]n nicht gut verstanden -- ein Problem, das zu Programmen geführt hat, die nicht so leistungsfähig sind, wie sie sein könnten.

	Dieser Artikel beschreibt die AWT und Swing Malmechanismen im Einzelnen. Sein Zweck ist, Entwicklern zu helfen, korrekten und leistungsfähigen GUI Malcode zu schreiben. Während der Artikel die allgemeinen Malmechanismen umfaßt (wo und wann man darstellt), erklärt er nicht, wie man die Swing Graphiken APIs benutzt, um korrekte Graphiken darzustellen. Um zu erlernen wie man nette Graphiken macht, besichtigen Sie bitte die [http://~~java~~.~~sun~~.com/~~products~~/~~java-media~~/2D/index.~~jsp~~ Java 2D Website].		Dieser Artikel beschreibt die AWT und Swing Malmechanismen im Einzelnen. Sein Zweck ist, Entwicklern zu helfen, korrekten und leistungsfähigen GUI Malcode zu schreiben. Während der Artikel die allgemeinen Malmechanismen umfaßt (wo und wann man darstellt), erklärt er nicht, wie man die Swing Graphiken APIs benutzt, um korrekte Graphiken darzustellen. Um zu erlernen wie man nette Graphiken macht, besichtigen Sie bitte die [http://docs.oracle.com/javase/tutorial/2d/index.html Java 2D Website].

	=Entwicklung des Swing Malsystems=		=Entwicklung des Swing Malsystems=

AndreUhres: /* Der RepaintManager */

2011-12-13T16:01:11Z

Der RepaintManager

← Nächstältere Version		Version vom 13. Dezember 2011, 16:01 Uhr
Zeile 311:		Zeile 311:

	==Der RepaintManager ==		==Der RepaintManager ==
	Der Zweck der Swingklasse "RepaintManager" ist, die Leistungsfähigkeit der repaint Verarbeitung auf einer Swing Containerhierarchie zu maximieren, und auch zur Implementierung des "revalidation" Mechanismus von Swing (letzteres wird das Thema für einen weiteren Artikel sein, siehe auch: [http://www.csie.ntu.edu.tw/~piaip/docs/Swing/Chapter2html/ Swing Mechanics] (oder [http://webcache.googleusercontent.com/search?q=cache:http://www.csie.ntu.edu.tw/~piaip/docs/Swing/Chapter2html/ Swing Mechanics]) und [http://www.java-forum.org/de/viewtopic.php?p=431845#431845 Validierung mit Swing]). Sie implementiert den repaint Mechanismus, indem sie alle repaint Anträge von Swing Komponenten abfängt (also werden sie nicht mehr durch das AWT verarbeitet) und ~~seinen~~ eigenen Zustand beibehält in Bezug auf das, was aktualisiert werden ~~muß~~ (bekannt als "dirty regions"). Schließlich benutzt sie invokeLater(), um die anstehenden Anträge auf dem "event dispatching thread" zu verarbeiten, wie im Abschnitt "Malverarbeitung" beschrieben (Option b).		Der Zweck der Swingklasse "RepaintManager" ist, die Leistungsfähigkeit der repaint Verarbeitung auf einer Swing Containerhierarchie zu maximieren, und auch zur Implementierung des "revalidation" Mechanismus von Swing (letzteres wird das Thema für einen weiteren Artikel sein, siehe auch: [http://www.java-forum.org/de/viewtopic.php?p=431845#431845 Validierung mit Swing]). Sie implementiert den repaint Mechanismus, indem sie alle repaint Anträge von Swing Komponenten abfängt (also werden sie nicht mehr durch das AWT verarbeitet) und ihren eigenen Zustand beibehält in Bezug auf das, was aktualisiert werden muss (bekannt als "dirty regions", also "verschmutzte Bereiche"). Schließlich benutzt sie invokeLater(), um die anstehenden Anträge auf dem "event dispatching thread" zu verarbeiten, wie im Abschnitt "Malverarbeitung" beschrieben (Option b). [Der RepaintManager wird eine Serie von Malanträgen möglichst zusammenfassen, wenn (und nur wenn) der "Anführer" der Serie mit invokeLater verschickt wurde, aber noch nicht auf dem EDT verarbeitet wurde.]

	Für die meisten Programme kann der RepaintManager als Teil des internen Systems von Swing angesehen werden und praktisch ignoriert werden. Jedoch liefert seine API den Programmen die Möglichkeit einer feineren Steuerung von bestimmten Aspekten des Zeichnens.		Für die meisten Programme kann der RepaintManager als Teil des internen Systems von Swing angesehen werden und praktisch ignoriert werden. Jedoch liefert seine API den Programmen die Möglichkeit einer feineren Steuerung von bestimmten Aspekten des Zeichnens.

AndreUhres: Änderung 4438 von AndreUhres (Diskussion) wurde rückgängig gemacht.

2010-10-09T07:45:26Z

Änderung 4438 von AndreUhres (Diskussion) wurde rückgängig gemacht.

← Nächstältere Version		Version vom 9. Oktober 2010, 07:45 Uhr
Zeile 351:		Zeile 351:

	Anmerkung: da die Default-Implementierung von Swing einen einzigen RepaintManager instanziert, ist das "mycomponent" Argument irrelevant.		Anmerkung: da die Default-Implementierung von Swing einen einzigen RepaintManager instanziert, ist das "mycomponent" Argument irrelevant.

	Beim Drucken von Swing-Komponenten müssen wir sicherstellen, dass die Doppelpufferung ausgeschaltet ist, bevor wir drucken (siehe auch [http://www.apl.jhu.edu/~hall/java/Swing-Tutorial/Swing-Tutorial-Printing.html Swing Tutorial Printing]):

	~~<code=java> public int print(Graphics g, PageFormat pageFormat, int pageIndex) {~~
	~~if (pageIndex > 0) {~~
	~~return(NO_SUCH_PAGE);~~
	~~} else {~~
	~~Graphics2D g2d = (Graphics2D)g;~~
	~~g2d.translate(pageFormat.getImageableX(), pageFormat.getImageableY());~~
	~~disableDoubleBuffering(componentToBePrinted);~~
	~~componentToBePrinted.paint(g2d);~~
	~~enableDoubleBuffering(componentToBePrinted);~~
	~~return(PAGE_EXISTS);~~
	}
	}

	~~public static void disableDoubleBuffering(Component c) {~~
	~~RepaintManager currentManager = RepaintManager.currentManager(c);~~
	~~currentManager.setDoubleBufferingEnabled(false);~~
	}

	~~public static void enableDoubleBuffering(Component c) {~~
	~~RepaintManager currentManager = RepaintManager.currentManager(c);~~
	~~currentManager.setDoubleBufferingEnabled(true);~~
	}
	}
	~~</code=java>~~

	==Swing Malrichtlinien ==		==Swing Malrichtlinien ==

AndreUhres: /* Globale Steuerung der Doppelpufferung */

2010-10-09T07:25:57Z

Globale Steuerung der Doppelpufferung

← Nächstältere Version		Version vom 9. Oktober 2010, 07:25 Uhr
Zeile 351:		Zeile 351:

	Anmerkung: da die Default-Implementierung von Swing einen einzigen RepaintManager instanziert, ist das "mycomponent" Argument irrelevant.		Anmerkung: da die Default-Implementierung von Swing einen einzigen RepaintManager instanziert, ist das "mycomponent" Argument irrelevant.

			Beim Drucken von Swing-Komponenten müssen wir sicherstellen, dass die Doppelpufferung ausgeschaltet ist, bevor wir drucken (siehe auch [http://www.apl.jhu.edu/~hall/java/Swing-Tutorial/Swing-Tutorial-Printing.html Swing Tutorial Printing]):

			<code=java> public int print(Graphics g, PageFormat pageFormat, int pageIndex) {
			if (pageIndex > 0) {
			return(NO_SUCH_PAGE);
			} else {
			Graphics2D g2d = (Graphics2D)g;
			g2d.translate(pageFormat.getImageableX(), pageFormat.getImageableY());
			disableDoubleBuffering(componentToBePrinted);
			componentToBePrinted.paint(g2d);
			enableDoubleBuffering(componentToBePrinted);
			return(PAGE_EXISTS);
			}
			}

			public static void disableDoubleBuffering(Component c) {
			RepaintManager currentManager = RepaintManager.currentManager(c);
			currentManager.setDoubleBufferingEnabled(false);
			}

			public static void enableDoubleBuffering(Component c) {
			RepaintManager currentManager = RepaintManager.currentManager(c);
			currentManager.setDoubleBufferingEnabled(true);
			}
			}
			</code=java>

	==Swing Malrichtlinien ==		==Swing Malrichtlinien ==

AndreUhres: /* Der RepaintManager */

2010-10-09T04:34:18Z

Der RepaintManager

← Nächstältere Version		Version vom 9. Oktober 2010, 04:34 Uhr
Zeile 311:		Zeile 311:

	==Der RepaintManager ==		==Der RepaintManager ==
	Der Zweck der Swingklasse "RepaintManager" ist, die Leistungsfähigkeit der repaint Verarbeitung auf einer Swing Containerhierarchie zu maximieren, und auch zur Implementierung des "revalidation" Mechanismus von Swing (letzteres wird das Thema für einen weiteren Artikel sein, siehe auch: [http://www.csie.ntu.edu.tw/~piaip/docs/Swing/Chapter2html/ Swing Mechanics] und [http://www.java-forum.org/de/viewtopic.php?p=431845#431845 Validierung mit Swing]). Sie implementiert den repaint Mechanismus, indem sie alle repaint Anträge von Swing Komponenten abfängt (also werden sie nicht mehr durch das AWT verarbeitet) und seinen eigenen Zustand beibehält in Bezug auf das, was aktualisiert werden muß (bekannt als "dirty regions"). Schließlich benutzt sie invokeLater(), um die anstehenden Anträge auf dem "event dispatching thread" zu verarbeiten, wie im Abschnitt "Malverarbeitung" beschrieben (Option b).		Der Zweck der Swingklasse "RepaintManager" ist, die Leistungsfähigkeit der repaint Verarbeitung auf einer Swing Containerhierarchie zu maximieren, und auch zur Implementierung des "revalidation" Mechanismus von Swing (letzteres wird das Thema für einen weiteren Artikel sein, siehe auch: [http://www.csie.ntu.edu.tw/~piaip/docs/Swing/Chapter2html/ Swing Mechanics] (oder [http://webcache.googleusercontent.com/search?q=cache:http://www.csie.ntu.edu.tw/~piaip/docs/Swing/Chapter2html/ Swing Mechanics]) und [http://www.java-forum.org/de/viewtopic.php?p=431845#431845 Validierung mit Swing]). Sie implementiert den repaint Mechanismus, indem sie alle repaint Anträge von Swing Komponenten abfängt (also werden sie nicht mehr durch das AWT verarbeitet) und seinen eigenen Zustand beibehält in Bezug auf das, was aktualisiert werden muß (bekannt als "dirty regions"). Schließlich benutzt sie invokeLater(), um die anstehenden Anträge auf dem "event dispatching thread" zu verarbeiten, wie im Abschnitt "Malverarbeitung" beschrieben (Option b).

	Für die meisten Programme kann der RepaintManager als Teil des internen Systems von Swing angesehen werden und praktisch ignoriert werden. Jedoch liefert seine API den Programmen die Möglichkeit einer feineren Steuerung von bestimmten Aspekten des Zeichnens.		Für die meisten Programme kann der RepaintManager als Teil des internen Systems von Swing angesehen werden und praktisch ignoriert werden. Jedoch liefert seine API den Programmen die Möglichkeit einer feineren Steuerung von bestimmten Aspekten des Zeichnens.

AndreUhres: /* "optimiert" zeichnen */

2010-10-09T04:00:59Z

"optimiert" zeichnen

← Nächstältere Version		Version vom 9. Oktober 2010, 04:00 Uhr
Zeile 237:		Zeile 237:
	Indem es die Eigenschaft "isOptimizedDrawingEnabled" überprüft, kann Swing schnell seine Suche nach überlappenden Komponenten zur repaint Zeit eingrenzen.		Indem es die Eigenschaft "isOptimizedDrawingEnabled" überprüft, kann Swing schnell seine Suche nach überlappenden Komponenten zur repaint Zeit eingrenzen.

	Da "isOptimizedDrawingEnabled" eine read-only Eigenschaft ist, ist also der einzige Weg, wie Komponenten den Default-Wert ändern können, die Klasse zu erweitern und diese Methode zu überschreiben, um den gewünschten Wert zurückzugeben. Alle standard Swingkomponenten geben "true" für diese Eigenschaft zurück, außer JLayeredPane, JDesktopPane und JViewPort.		Da "isOptimizedDrawingEnabled" eine read-only Eigenschaft ist, ist also der einzige Weg, wie Komponenten den Default-Wert ändern können, die Klasse zu erweitern und diese Methode zu überschreiben, um den gewünschten Wert zurückzugeben. Alle standard Swingkomponenten geben "true" für diese Eigenschaft zurück, außer JLayeredPane, JDesktopPane und JViewPort. Wenn wir also z.B. ein JPanel mit einem Layout haben, das überlappende Komponenten zulässt (wie "OverlayLayout"), dann ist es gewöhnlich notwendig, JPanel zu erweitern und isOptimizedDrawingEnabled() zu überschreiben, um "false" zurückzugeben.

	==Die Malmethoden ==		==Die Malmethoden ==

AndreUhres: /* Malen in AWT und Swing */

2010-10-09T02:44:34Z

Malen in AWT und Swing

← Nächstältere Version		Version vom 9. Oktober 2010, 02:44 Uhr
Zeile 9:		Zeile 9:
	Übersetzung: André Uhres (Ich habe bei Sun die Erlaubnis angefragt, diesen Artikel zu übersetzen und hier zu veröffentlichen)		Übersetzung: André Uhres (Ich habe bei Sun die Erlaubnis angefragt, diesen Artikel zu übersetzen und hier zu veröffentlichen)

	*HINWEIS vom Übersetzer: Zum Einstieg in das Malen mit Swing ist auch der folgende kurze und praxisorientierte Artikel gut geeignet: ~~http~~:~~//wiki.byte-welt.net/wiki/Malen_in_Swing_Teil_1:_der_grundlegende_Mechanismus~~		*HINWEIS vom Übersetzer: Zum Einstieg in das Malen mit Swing ist auch der folgende kurze und praxisorientierte Artikel gut geeignet: [[Malen in Swing Teil 1: der grundlegende Mechanismus]]

	In einem graphischen System ist normalerweise ein Fensterdarstellungstoolkit dafür verantwortlich, einen Rahmen zur Verfügung zu stellen, der es relativ einfach macht, auf einer graphischen Benutzerschnittstelle (GUI) die richtigen Bits zur richtigen Zeit darzustellen.		In einem graphischen System ist normalerweise ein Fensterdarstellungstoolkit dafür verantwortlich, einen Rahmen zur Verfügung zu stellen, der es relativ einfach macht, auf einer graphischen Benutzerschnittstelle (GUI) die richtigen Bits zur richtigen Zeit darzustellen.