Die Weiterentwicklung von Java, insbesondere der Standardbibliotheken, ist Fluch und Segen zugleich. Wie beim Druck- oder Font-API (Coffeeshops [1] und [2]) gibt es auch für die Bildbearbeitung mehrere API-Generationen. Dabei ersetzen die neuen Bibliotheken ihre Vorgänger nicht, sondern ergänzen und erweitern sie.
Die Anfänge
Den Höhepunkt seiner Popularität erreichte Java durch Applets auf Webseiten. Bilder spielten hier in Form von Animationen und kleinen Gifs auf Buttons und anderen Schaltflächen eine besondere Rolle. Sie lagerten nicht auf der Festplatte, waren also nicht immer sofort verfügbar.
In solchen Anwendungsfällen kommt das Push Model zum Einsatz. Die Klasse »java.awt.Image« zeigt Bilder an, ändert sie aber nicht. »Image«-Objekte entstehen aus einer Pipeline von »ImageProducer«- zu »ImageConsumer«-Objekten, am Ende geschieht die Ausgabe über den »Graphics«-Kontext eines AWT-Objekts. Das Push-Modell trägt seinen Namen, weil allein der Producer den Fortschritt bestimmt. Somit eignet es sich auch für langsame Netzwerke.
Die Dokumentation der Klasse »java.awt.MediaTracker«, die Bilder asynchron herunterlädt, enthält ein Beispiel. Die Methode »getImage()« der »Applet«-Klasse liefert zwar sofort ein »Image«-Objekt, aber normalerweise startet erst die »drawImage()«-Methode des »Graphics«-Objekts den Download. »MediaTracker« lädt dagegen auch mehrere Bilder im Voraus asynchron herunter.
Ein simpler Bildbetrachter
Die Beispiele aus den Listings 1 und 2 zeigen die Implementation eines einfachen Bildbetrachters auf Basis von »awt.Image« (siehe Abbildung 1). Der Benutzer übergibt die Dateinamen als Kommandozeilenparameter und blättert dann über das Menü in der Liste vor und zurück. Die Methode »setImages()« (Zeilen 123 bis 129, Listing 1) erzeugt ein Array aus »Image«-Objekten. Das kostet keine Performance, denn diese Objekte enthalten wie oben beschrieben keine Bilddaten.
022: import java.io.*;
023: import java.awt.*;
024: import java.awt.event.*;
025: import javax.swing.*;
026:
034: public class ImageViewer extends JFrame {
035:
066: public ImageViewer(String title, ImagePanel panel) {
067: super(title);
068: setJMenuBar(getMenu());
069: iImagePanel = panel;
070: iScrollPane = new JScrollPane((JPanel) iImagePanel);
071: getContentPane().add(iScrollPane);
072: setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
073: setLocation(100, 100);
074: setVisible(false);
075: }
076:
123: protected void setImages(String[] filenames) throws IOException {
124: Image[] imgArray = new Image[filenames.length];
125: for (int i=0;i<filenames.length;++i) {
126: imgArray[i] = Toolkit.getDefaultToolkit().getImage(filenames[i]);
127: }
128: setFiles(imgArray);
129: }
130:
137: protected void setImage(Image img) {
138: iImagePanel.setImage(img);
139: iScrollPane.getViewport().setViewPosition(new Point(0,0));
140: }
203: }
|
032: public class ImagePanel1 extends JPanel implements ImagePanel {
033:
100: public void paint(Graphics g) {
101: if (iImage != null) {
102: g.drawImage(iImage,0,0,this);
103: }
104: }
106: }
|
Abbildung 1: Die Bilder durchlaufen eine dreistufige Pipeline von der Bildquelle bis zur Anzeige auf dem Bildschirm (siehe Listings 1 und 2).
Der Bildbetrachter setzt ein »ImagePanel« ein. Dabei handelt es sich um nichts anderes als ein »JPanel« mit eigener »paint()«-Methode (Zeilen 100 bis 104, Listing 2). Erst die Ausgabe in Zeile 102 liest das Bild ein. Auf langsamen Rechnern macht sich dieser Effekt dadurch bemerkbar, dass bei der ersten Anzeige deutlich mehr Zeit verstreicht als bei späteren. Der Bildbetrachter ist damit bereits komplett, die »Image«-Objekte ermöglichen nicht wesentlich mehr Funktionalität. Mehr geht erst mit der nächsten API-Generation.
« Zurück
1
2
3
4
5
Weiter »