Gefühlte 90% aller HTML5-Demos im Web verwenden das Canvas-Element. Das machen sie auch nicht ohne Grund, denn das Element und seine APIs ermöglichen etwas Spektakuläres, das vorher in Browsern nicht möglich war: das Zeichnen und Animieren beliebiger Formen und Farben, bis auf den letzten Pixel kontrollierbar. Das Canvas-Element eröffnet ganz neue Möglichkeiten, die weit über das über die bunten Kästchen hinausgehen, die man allein CSS und JavaScript durch den Browser schubsen kann, von statischen Diagrammen bis zum 3D-Shooter kann man alles rendern, was das Herz begehrt.
Teil 3 einer fünfteiligen Artikelserie rund um HTML5 für das Blog von Microsoft Deutschland.
Kommentare (21)
Herr Gabriel ¶
17. März 2011, 10:03 Uhr
Ich finds ja großartig, dass du Artikel auf einem MS Blog veröffentlichst.
Maik ¶
17. März 2011, 12:01 Uhr
Ersetze „das vorher in Browsern nicht möglich war“ durch „das vorher in Browsern nur über SVG möglich war – und dafür sind die meisten Webentwickler zu faul“. Nichts gegen Canvas an sich, aber die Behauptung, dass scriptingfähige Vektorgrafik im Browser etwas völlig neues sei, ist falsch.
Peter ¶
17. März 2011, 12:04 Uhr
Aber das Canvas-Element macht doch gar keine Vektorgrafiken?
Maik ¶
17. März 2011, 12:15 Uhr
Die Sachen, die man auf einen Canvas so malen kann, sind schon klassische Vektorgrafikobjekte. Canvas erzwingt allerdings, dass nach jedem Schritt das Bild in eine Pixelgrafik flachgepresst wird, die Vektordarstellung geht verloren, wenn man sie sich nicht selber merkt; wenn man möchte, kann man das zum Anlass nehmen, zu sagen, Canvas sei Pixelgrafik.
Fest steht jedenfalls, was mit Canvas 2D so geht, ist eine Teilmenge dessen, was SVG bietet, und damit nicht grundsätzlich neu.
Robert ¶
17. März 2011, 12:28 Uhr
Was bleibt noch zu sagen...
Peter ¶
17. März 2011, 12:37 Uhr
Zitat Maik:
Du sieht das sehr falsch. Der 2D-Kontext von Canvas hat nichts mit Vektorgrafik zu tun. Nur weil das Erzeugen eines bunten Rechtecks in beiden Fällen ähnlich aussieht, heißt das nicht, dass das Endergebnis gleich ist. Das Bild wird nicht zu einer , sondern beim ganzen Konzept geht es vom Start weg um das Bearbeiten einer Bitmap, mit allen Vor- und Nachteilen im Vergleich zu einer Vektorgrafik.
In den meisten Fällen wird man mit dem Canvas-Element keine bunten Vektorformen zeichnen wollen, denn dafür steht in der Tat SVG bereit. Aber der Punkt „bis auf den letzten Pixel kontrollierbar“ ist der entscheidend und nicht, so wie du es darstellst, ein Kollateralschaden. Ohne Canvas wäre sowas nicht möglich.
Florian ¶
17. März 2011, 13:04 Uhr
Das Canvas-Element leidet doch auch unter der Tatsache, dass Fonts (in manchen Sytemen) gehintet und praktisch überall gesmoothed (Quartz, ClearType, ...) werden. Da Smoothing ja eigentlich nur für horizontale Schriften konzipiert ist, sieht die Schrift also auch hier bei Drehungen aus wie Konfetti?!
Das ist sparsam und ein klares Argument gegen die Vektortheorie.
Fehlende Zooming-Fähigkeit und die Angabe von Koordinaten in Pixeln machen die Argumentation perfekt.
Ich will nicht sagen, dass nicht bestimmte Algorithmen (z.B. zur Zeichnung eines schrägen Vierecks) tatsächlich aus der Vektor-Geometrie entlehnt sind. Aber das gesamte Canvas-Element in Vektoren zu definieren wäre ganz schön ressourcenintensiv. Halte ich in Zeiten ohne hardwarebeschleunigtes Rendering für unwahrscheinlich. Und - wo wir doch kurz vor hardwarebeschleunigtem Rendering stehen - für unsinnig.
Wäre ich Browser-Hersteller würd ichs nicht machen oder auch nur versuchen.
Und der Standard ist wohl auch eher auf Pixel angelegt ... er spricht zumindest von "[...] the actual bitmap that the user agent [...]". Bitmaps sind nunmal in Pixeln.
Dirk ¶
17. März 2011, 13:16 Uhr
Lieber Maik, habe mal ein kurzes Search über Peters Artikel gemacht. Konnte das Wort "Vektor" leider nirgends finden, weswegen es mir scheint, als ob Du ihm hier eine Aussage vorwirfst die er überhaupt nicht gemacht hat.
Deine Darstellung hingegen, dass es sich bei den "Sachen die man auf eine Canvas so malen kann" um Vektorobjekte handelt, ist unzutreffend. Die Canvas kennt keine "Objekte". Ein Vergleich zwischen Canvas und SVG ist ungefähr genauso sinnvoll wie ein Vergleich zwischen Lego und Playmobil. Mit Canvas "geht" erstmal alles was man scripten kann, mit SVG "geht" alles was a) in der Spezifikation steht und b) in die Viewer implementiert wurde. SVG ist deklarativ, performt dabei aber ungefähr um den Faktor 20 schlechter und hat deswegen schlichtweg einen anderen Use-Case.
Schepp ¶
17. März 2011, 14:08 Uhr
Canvas wurde von Apple in die WHATWG eingebracht und die haben es von ihrer Core Graphics API abgeleitet, die wiederum starke Anleihen an Display Postscript macht. Und das wiederum unterscheidet sich von normalem PostScript durch folgendes:
Maik ¶
17. März 2011, 14:09 Uhr
Zitat Peter:
Er ist aber kein Alleinstellungsmerkmal gegenüber SVG + Javascript. SVG kennt Pixel als Maßeinheit sowohl für die Zeichenfläche als auch für die gezeichneten Objekte. Es beschränkt einen bloß nicht darauf.
Peter ¶
17. März 2011, 14:25 Uhr
Zitat Maik:
Doch. Doch genau das ist es, ein Alleinstellungsmerkmal. Man kann jeden einzelnen Bildpunkt der Bitmap auslesen, umbauen und wieder zurückschreiben. Oder das darzustellende Bild komplett aus einzelnen Bildpunkten zusammenstückeln. Das geht mit SVG nicht.
Florian ¶
17. März 2011, 14:34 Uhr
Zitat MaikEr ist aber kein Alleinstellungsmerkmal gegenüber SVG + Javascript. SVG kennt Pixel als Maßeinheit sowohl für die Zeichenfläche als auch für die gezeichneten Objekte. Es beschränkt einen bloß nicht darauf.
Ach herrje, jetzt vergleichst du Arschbacken und Kuchenbacken.
Nur weil die beiden Pixel heissen kommt letztendlich nicht das gleiche heraus.
Ein Informatiker könnte dir jetzt vorwerfen, dass du das Prinzip der Vektorgrafiken nicht verstanden hast, weil du die Berechnungsgröße PPI vergisst.
Zwei Cases in SVG:
1. Du sagst "Hey du SVG, du bist jetzt 1024 x 768 Pixel groß" und "Hey Browser, hier hast du ein SVG, zeig mal an in 1024 x 768 Pixel"
2. Du sagst "Hey du SVG, du bist jetzt 1024 x 768 Pixel groß" und "Hey Browser, hier hast du ein SVG, zeig mal an in 400 x 300 Pixel"
Alle Maße heißen gleich, haben aber eine unterschiedliche Bedeutung.
Die Beiden sehen schon unterschiedlich aus. (Zumindest bei mir ergibt sich eine signifikant unterschidliche Ausgabegröße.)
Canvas kennt keine PPIs.
Maik ¶
17. März 2011, 15:06 Uhr
@Peter, doch, das geht eben, wenn man denn unbedingt will. SVG ist sehr umfangreich.
@Florian, und bei Canvas kann dir nicht passieren, dass jemand die Zoomfunktion benutzt? Oder dass der Browser weiß, dass er ein hochauflösendes Display hat, und automatisch aus jedem Canvaspixel bei der Ausgabe vier Screenpixel macht?
Ich bleibe dabei: Canvas ist keine Innovation, sondern lediglich die Reduktion von SVG auf eine deppenkompatible (und wegen Einfachheit schneller renderbare) Teilmenge.
Florian ¶
17. März 2011, 15:25 Uhr
Zitat Maik:
Hast du gerade deine eigene Argumentation ad absurdum geführt? ... ja, hast du.
Peter ¶
17. März 2011, 15:25 Uhr
Zitat Maik:
Also wenn du Canvas für "deppenkompatibler" als SVG hältst komme ich nicht umhin, dich der totalen Ahnungslosigkeit zu verdächtigen. Der Umgang mit Canvas ist doch gerade deshalb schwieriger, weil es auf einem niedrigerem Level ansetzt. Oder du verstehst Vektorgrafik als einzig mögliche höhere Abstraktionsebene einer Pixelgrafik und kannst/willst dir nicht ausmalen, dass Lowlevel-Pixelei auch nützlich sein kann.
Maik ¶
17. März 2011, 15:44 Uhr
Die Nützlichkeit von Canvas habe ich doch gar nicht angezweifelt. Ob Canvas wirklich einfacher ist als SVG, ist eine interessante Frage, aber auch nicht der Punkt.
Meine ursprüngliche Aussage war und ist: Alles, was mit Canvas geht, konnte und kann man auch mit SVG + Javascript schon machen. In diesem Sinne ist Canvas nicht „neu“.
Ein überzeugendes Gegenargument kam bisher nicht. Lediglich Falschaussagen (SVG könne nicht mit Pixeln umgehen), zutreffende Aussagen, die aber meiner nicht widersprechen (SVG sei oft langsamer als Canvas), und ein paar unnötige Ausrutscher im Tonfall.
Peter ¶
17. März 2011, 15:51 Uhr
Zitat Maik:
Dann mach mal mit SVG.
Maik ¶
17. März 2011, 17:03 Uhr
Ich bezweifle, dass irgendein Browser die nötigen SVG-Operationen implementiert hat. Nicht, dass deine Canvasversion in allen ginge. In der Spezifikation stehen sie, ab SVG 1.2 in schön, davor muss man das Video etwas ekelig via foreignObject einbinden. Nein, ich mache keine Referenzimplementierung. Fühl dich völlig frei, das als Sieg in der Debatte zu werten, wenn du das brauchst.
Florian ¶
17. März 2011, 17:27 Uhr
Zitat Maik:
Irgendwie bezweifle ich, dass es hier um einen "Sieg" geht. Es geht um semantische Richtigkeit.
Anfangs hast du übrigens etwas anderes behauptet, wenn deine Rechtfertigung allerdings wirklich in einem "Jedem seine Meinung, trotzdem ist mein richtiger" mündet, stelle ich dir zu überlegen, ob , und nicht vielleicht auch gleich sind.
Nicht jeder Vergleich hinkt ... aber Canvas ist so neu wie auch . Einfacher (insbesopndere einfacher für Leute zu verstehen, die von Vektor-Geometrie wenig Ahnung haben), kompakter, performanter, semantisch richtiger und wohl in jedem Browser verfügbar.
Florian ¶
17. März 2011, 17:29 Uhr
Arrgh, da fehlen <audio>, <video>, <object>.
fwolf ¶
20. März 2011, 17:57 Uhr
Zitat Peter:
Randbemerkung: Dieses vielfach zitierte Teil sagt: "nur Firefox". Damit ist wohl Firefox 4.0 gemeint - in Firefox 3.6.15 (Linux / i686) läufts jedenfalls nicht.
cu, w0lf.