Im vorigen Teil habe ich eine kurze Einführung in das Thema Auflösungsunabhängigkeit gegeben. Der vorliegende Teil erläutert, welche technischen Beschränkungen das Erstellen von qualitativ hochwertigen, auflösungsunabhängigen Icons erschweren.
Der Raster-Ansatz
Bei Rastergrafiken (oder Bitmap-Grafiken) wird ein Bild als ein Raster von Pixeln beschrieben, in dem jeder Pixel einen anderen Farbwert besitzt. Eine Rastergrafik kann zwar schnell gezeichnet werden, aber es ist nicht möglich, sie ohne Qualitätsverlust hoch- oder herunterzuskalieren, da das Raster nur voneinander unabhängige Informationen über einzelne Pixel, nicht jedoch ganzheitliche Informationen über das zu skalierende Objekt enthält.
Um Qualitätsverluste beim Icon Design zu vermeiden, ist es Usus eine eigene Rastergrafik für jede Größe zu erstellen, in der das Icon dargestellt werden soll. Typischerweise werden diese verschiedenen Iconversionen in einem gemeinsamen Dateiformat, wie .ICO (auf der Windows Plattform) oder .ICNS (auf der Mac Plattform) gesammelt. Der Programmierer der betreffenden Anwendung muss dann entscheiden, welche Version des Icons unter welchen Bedingungen dargestellt wird.
Zu Windows XP-Zeiten enthielt eine typische .ICO-Datei verschiedene Icon-Versionen von 16×16, 32×32 und 48×48 Pixel (manchmal außerdem 24×24 Pixel). Mac OS X Tiger unterstützte schon Größen bis zu 128×128 Pixel, gesammelt in einer .ICNS-Datei. Um dem Problem bei Geräten mit hohen ppi-Zahlen zu begegnen, wurde das.ICO-Format in Windows Vista und Windows 7 so erweitert, dass es eine zusätzliche 256×256 Pixel Iconversion unterstützt.
Doch damit nicht genug. In Mac OS X Leopard stellte Apple gigantische 512×512 Pixel Icons vor (z.B. für Front Row) und begründete deren Notwendigkeit mit der Auflösungsunabhängigkeit. Diese Art von Wettrüsten zeigt das Problem des einfachen Rastergrafik-Ansatzes: Diese Grafiken lassen sich einfach nicht gut skalieren und man braucht eine Menge verschiedener Größen eines Icons, um alle existierenden Monitore bedienen zu können.
Dazu gesellt sich folgendes Problem: ein 512×512 Pixel Icon braucht beinahe 800 KB des Hauptspeichers und ist selbst in komprimierter Form noch von erheblicher Größe. In Zeiten von Rich Internet Applications (RIAs), in denen Ressourcen über das Netzwerk zur Verfügung gestellt werden, sollte man dies nicht außer Acht lassen. Vielleicht übertreibe ich hier ein bisschen, da diese enormen Größen hauptsächlich für Desktop Icons – Icons, die eine Anwendung auf dem Desktop repräsentieren – nötig sind. Zumindest vorerst bleibt der Großteil der Icons innerhalb einer Anwendung kleiner als 64×64 Pixel. Auch wenn hier im Moment noch kein Problem auftritt, so werden wir doch in Zukunft damit konfrontiert werden. Mit wachsender Pixeldichte werden auch Nicht-Desktop-Icons größer werden müssen. Wenn eine Anwendung hunderte von Icons enthält und jedes dieser Icons in großen Abmesungen zur Verfügung gestellt wird, so wird die Speicherauslastung zu einem bedeutenden Faktor – besonders im Kontext von Rich Internet Applications.
Der Vektor-Ansatz
Der Einsatz von Vektoren ist ein gängiges Mittel zur Erstellung von Grafiken, die ohne Qualitätsverlust auf verschiedene Größen skalierbar sind. In einer perfekten Welt würden wir daher unsere Icons einfach in einem Bildverarbeitungsprogramm erstellen, das Vektorgrafiken unterstützt (wie z.B. Photoshop, Illustrator oder Inkscape) und sie in ein bekanntes Vektorformat, wie SVG, PDF, XAML oder (das etwas weniger bekannte) JavaFX Script exportieren, welches seinerseits wiederum direkt in unsere Anwendung geladen und dort dargestellt werden kann.
Langsame Zeichengeschwindigkeit
Das erste Problem ist aber, dass vektor-basierte Grafiken eine beträchtliche Zeit brauchen, um direkt gezeichnet zu werden (d.h. da jedesmal, wenn die Grafik auf dem Bildschirm angezeigt werden soll, die Vektordaten in Pixelinformation konvertiert werden müssen).
Warum ist es aber dann in modernen Computerspielen möglich, super-realistische dreidimensionale Szenen mit dynamischen Licht- und Schatteneffekten sowie flüssigen Animationen in Echtzeit zu rendern, während es unglaublich langsam ist, ein vektor-basiertes Icon zu rendern, das nur zwei Dimensionen nutzt, nicht animiert ist und seine Licht- und Schatteneffekte bereits „eingemeißelt“ hat? Nun, moderne Spiele nutzen ausgiebig die Möglichkeiten moderner Grafik-Hardware, während die meisten Anwendungen auf Software-Frameworks basieren, die sich auf Abstraktionsschichten und Rückwärtskompatibilität fokussieren und die Grafik-Hardware mit anderen Software-Frameworks teilen müssen, ohne in der Lage zu sein, direkt alle Möglichkeiten der Grafik-Hardware zu nutzen. Im Detail ist das Ganze natürlich noch komplexer, aber ich möchte hier nicht zu weit vom Thema abschweifen. Der Kernpunkt ist dieser: vektor-basierte Icons direkt zu zeichnen könnte in der Theorie unglaublich schnell ablaufen, ist aber in der Praxis ärgerlich langsam – sogar zu langsam, um derzeit eine brauchbare Alternative zu sein.
Exportschwierigkeiten bei Vektor-Daten
Das zweite Problem ist, dass die Exportfunktionen der meisten hochmodernen vektor-basierten Programme relativ schlecht sind. Beliebte Iconeffekte, wie beispielsweise Schlagschatten oder Glanzeffekte werden beim Exportieren immer noch gerastert, was zu riesigen Zieldateien führt, die eine Menge Speicher benötigen und lange Ladezeiten verursacht und – was am lästigsten ist – viele Grafiken enthalten, die immer noch nicht vektor-basiert sind. Das bedeutet, dass man beim Export eines Icons letztendlich eine voluminöse PDF-, SVG- oder XAML-Datei erhält, die eigentlich ohne Qualitätsverlust unendlich skalierbar sein sollte, es aber nicht ist, da sie Rasterinformationen enthält. Weder eine neue Anwendung wie Microsoft® Expression® Blend, die sich auflösungsunabhängigen UIs verschrieben hat, noch ein Platzhirsch wie Adobe® Illustrator kommen bei anspruchsvollen visuellen Effekten komplett ohne Rastergrafiken aus. Bezogen auf Illustrator schien das JavaFX Export Plugin (damaliger Projektname: Nile) vielversprechend, da es Schatteneffekte beim Export nicht rastert. Das Projekt befindet sich allerdings immernoch in den Kinderschuhen und leidet dementsprechend noch an einigen Kinderkrankheiten.
Das Vektor-Raster-Dilemma
Ein weiteres Problem, das die anderen beiden Probleme fast in den Schatten stellt, ist, dass eine einzelne vektor-basierte Beschreibung eines Icons, niemals ein gestochen scharfes, makelloses und ästhetisches Ergebnis in allen Größen, in denen das Icon dargestellt werden soll, liefern kann. Entweder erhält man ein wenig detailliertes Vektor-Icon, das in kleinen Größen gut aussieht, aber langweilig wirkt, sobald es in größeren Abmessungen dargestellt wird, oder man hat ein sehr detailliertes Vektor-Icon, das in großen Abmessungen fantastisch aussieht, aber in kleinen Abmessungen nur noch als Pixelhaufen erscheint.
Im nächsten Teil werde ich darauf eingehen, wie Centigrade mit diesen Einschränkungen umgeht und dennoch hochwertige Icons in verschiedenen Größen daraus resultieren.
