Future Web, Post 05

Ich habe mir vor einiger Zeit ein Chromebook gekauft, und das ist ein ganz eigenartiger Rechner: Es läuft nur eine einzige Applikation auf diesem Rechner: Google Chrome. Der Browser. Sonst nichts. Wirklich: nichts. Keine andere Applikation. Ein schrecklich benutzerunfreundlicher Rechner! Einen einzigen Vorteil hat dieses Biest: Es zwingt mich, über das Future Web nachzudenken. Das Future Web, das alles außer dem Browser von unserem Desktop verdrängen wird. Weil es nur noch das Web gibt. Sonst nichts. Wirklich: nichts. Keine andere lokale Applikation. Nur den Browser.

Schöne neue Welt: Das Web ist perfekt. Oder? Naja, vielleicht ist das Web ein bißchen textlastig. Dennoch: Das Web ist voller bunter Bilder, und nichts ist einfacher, als ein Photo mit einer digitalen Kamera zu machen und dieses Bild ins Web zu stellen. Man kann aber auch ein Bild in einem lokalen Graphik-Editor erstellen und es ins Netz stellen. Und wenn man für dieses Bild eines der Formate JPG, GIF, PNG oder SVG benutzt, dann kann man sich darauf verlassen, daß der Browser der Betrachterin das Bild rendert. Alles ist gut.

Surfen ist gut mit dem Chromebook. Blog lesen ist gut. Blog schreiben ist gut. Bilder hochladen ist gut. Video einbetten ist gut. Aber irgendwann habe ich mir gedacht, da ist doch eine Lücke!: Bilder malen im Browser, das geht nicht. Mit den all den schicken Web 2.0-Werkzeugen kannst Du am Ende des Tages doch nur schreiben und hochladen. Ist das alles? Ich habe angefangen, mir vorzustellen, daß dieser Browser als Frontend für eine Graphikapplikation genutzt werden kann. Also: daß der Browser nicht nur Bilder rendert, die er vom Server abgeholt hat, sondern selber eine Schnittstelle für Graphikapplikationen anbietet, Applikationen, die es ermöglichen, Graphiken im Browserfenster zu erzeugen. Natürlich mit WYSIWYG. Das gute alte MS Paint als Web-Applikation. Oder so ähnlich. Ist das Web doch nicht perfekt?

Klar, wie die Sache ausging: eine neue Runde beim altbekannten Hase-und-Igel-Spiel! Kaum hat man eine Frage vernünftig formuliert, schreit einer die Antwort: “Lösung ist schon da!” Auf jedem Fall ist es im ganzen Umfeld Web so: Meist kommt es einem so vor, als habe die Antwort die Frage überholt. (Das ist der Charme der Komplexitätstheorie: Da bleiben die Fragen ganz, ganz lange ohne Antwort! Wow, wenn ich es mir so überlege: Ich sollte umsatteln! Algorithmen und Datenstrukturen, ich komme!)

Aber es kam noch schlimmer: Nicht nur einer schreit die Antwort – es sind gleich zwei! Und die heißen HTML5 und SVG. (Naja, Java Applets sind wohl nie so richtig beliebt geworden, die vergesse ich jetzt.)

HTML5 bringt dem Webprogrammierer das canvas-Element, sprich die Leinwand. Und mit zugehörigen Graphik-Funktionen der Programmiersprache JavaScript kann man graphische Objekte auf dem canvas zeichnen. Der canvas speichert allerdings nicht die graphischen Objekte, sondern nur die “Pixelhaufen”, die das jeweilige graphische Objekt repräsentieren. Anders formuliert: Der canvas unterstützt Pixel-Graphiken. Für den Export von Pixel-Graphiken eignet sich das PNG-Format. Klar kann man also mit JavaScript das Programm MS Paint nachprogrammieren; hier ist ein simples Beispiel. Bei interaktiven Applikationen mit bewegten graphischen Objekten hat die Sache einen Haken: Der JavaScript-Programmierer muß dafür sorgen, daß der canvas – wie bei einem Zeichentrickfilm – in einem gegebenen Takt mit geeigneten (Zwischen-)Bildern gefüllt und widergegeben wird. In seinem recht übersichtlichen Tutorial  beschreibt Simon Sarris das so: “A canvas isn’t smart: it’s just a place for drawing pixels. If you ask it to draw something it will execute the drawing command and then immediately forget everything about what it has just drawn. This is sometimes referred to as an immediate drawing surface … we have to keep track ourselves of all the things we want to draw (and re-draw) … Canvas also has no built-in way of dealing with animation. If you want to make something that you’ve drawn move, you have to clear the entire canvas and redraw all of the objects with one or more of them in a new location. And you have to do it often, of course, if you want a semblance of animation or motion.”

Ganz anders SVG (Scalable Vector Graphics): SVG ist eine XML-basierte Sprache zur Beschreibung von graphischen Objekten. Diese graphischen Objekte werden selber Bestandteil des DOM-Baums! Die Graphik-Applikation arbeitet also direkt auf dem DOM-Baum. Im oben erwähnten Tutorial wird das wie folgt ausgedrückt: “[SVG] is sometimes referred to as a retained drawing surface, since SVG keeps a reference to everything drawn.” Naja, und für das Abspeichern des erstellten Bildes steht naheliegenderweise das SVG-Format zur Verfügung. Hier eine SVG/JS-Graphik-Bibliothek,  mit deren Operationen der Programmierer auf den DOM-Baum zugreifen kann. Für die Erzielung von Bewegungseffekten muß der entsprechend manipulierte DOM-Baum in geeigneten zeitlichen Abständen widergegeben werden. SVG hat Beschreibungselemente, die sich auf die Veränderung von Objekten über der Zeit beziehen.

Offensichtlich benötigt man also beide Techniken, und je nach Anwendungsfall kann der HTML5 canvas oder SVG die bessere Wahl sein. In diversen Tutorials im Netz wird gezeigt, wie sich beide miteinander verbinden lassen. Warum allerdings die Fa. Adobe die Unterstützung von SVG eingestellt hat, das verstehe ich nicht.

Auf jeden Fall gilt: Das Web ist perfekt. Und das Future Web erst recht.

Comments
One Response to “Future Web, Post 05”
  1. Jesper Zedlitz says:

    Da bei SVG die Browserhersteller wissen, welche Elemente auf sie zukommen, kann dafür gezielt optimiert werden. Ich war immer ganz erstaunt, dass selbst vor ein paar Jahren schon Handys Animationen mit SVG flüssig darstellen konnten – Beschleunigung in Hardware sei Dank.
    Mit WebGL besteht nun sogar die Möglichkeit der 3D-Darstellung im Browser. Die notwendige Berechnung wird an die Grafikkarte durchgereicht.