.: Daniel Melanchthon :.

Banging your head against a wall uses 150 Calories an hour.

GPU-powered HTML5 mit Internet Explorer 9, Chrome 7 und Firefox 4

GPU-powered HTML5 mit Internet Explorer 9, Chrome 7 und Firefox 4

  • Comments 17
  • Likes

Nachdem wir in der letzten Woche Internet Explorer 9 als Betaversion vorgestellt haben, drehen sich viele Diskussionen in der Presse und im Netz um die Unterschiede zwischen aktuellen Browserversionen und hierbei natürlich ganz besonders um die Geschwindigkeit bei der Darstellung von HTML5-Webseiten. Microsoft setzt mit Internet Explorer 9 ganz auf den Grafikprozessor (GPU): GPU-powered HTML5 bedeutet die Nutzung moderner Grafikchips (GPU) bei der Berechnung der Darstellung von Internetseiten.

Ted_FullGPU_1Um zu verstehen, wie die Grafikkarte bei der Darstellung helfen kann, muss man sich einmal die verschiedenen Schritte, die ein Browser zum Darstellen einer Internetseite durchführen muss, genauer anschauen. Mein Kollege Ted Johnson, Program Manager Lead for Web Graphics, erklärte in dem Artikel The Architecture of Full Hardware Acceleration of All Web Page Content auf dem englischsprachigen Internet Explorer Blog sehr ausführlich, welche Herausforderungen es dabei zu bewältigen gibt und wie die Architektur von Internet Explorer 9 ganz auf Geschwindigkeit ausgerichtet wurde. So beschleunigt Internet Explorer 9 alle drei Schritte vollständig, die zum Rendern einer Webseite notwendig sind:

  1. Content Rendering über Direct2D und DirectWrite
  2. Page Composition über Direct3D
  3. Desktop Composition über den Desktop Window Manager (DWM)

Im Ergebnis fühlt sich Internet Explorer 9 schon in der Beta rasend schnell beim Seitenaufbau an. Unabhängig davon ob es sich um modernste HTML5-Webseiten handelt oder um Klassiker wie Facebook, Ebay, Heise.de oder Spiegel Online - ich habe immer das Gefühl, als wenn eine Handbremse gelöst worden wäre. IE9 beschleunigt gerade nicht nur speziell auf ihn optimierte Seiten. Je nach Struktur und Inhalt spürt man die hohe Geschwindigkeit auch auf allen bisher existierenden Webseiten.

Aber natürlich schlafen unsere Konkurrenten Marktbegleiter ;-) nicht. Koinzidenz begründet zwar keine Korrelation und ist kein Beweis für Kausalität, aber eine Woche vor dem Veröffentlichungstermin unserer Beta stellte das Mozilla-Team Firefox 4 beta 5 vor, in dem die GPU-beschleunigte Wiedergabe standardmäßig zum ersten Mal aktiviert wurde. Google bloggte wiederum am Vortag unserer Veröffentlichung über den ersten Chrome 7 Canary build, bei dem man die Hardwarebeschleunigung durch Übergabe von Parametern manuell einschalten kann: chrome.exe --enable-webgl --enable-accelerated-compositing --enable-accelerated-2d-canvas.

Damit stehen mittlerweile drei Browser zur Verfügung, die jeweils mit Hardwarebeschleunigung werben. Allerdings ist Hardwarebeschleunigung keine binäre Funktion wie ein Ein-/Ausschalter. Wie effizient sie ist, kommt ganz auf die gewählte Implementierung an. Ich habe daher einmal alle drei Browser verschiedene Aufgaben durchführen lassen, um die Unterschiede zwischen den neuen GPU-beschleunigtem Rendering-Techniken im Vergleich zum früheren Softwarerendering aufzuzeigen. Als Testmaschine nahm ich einen Demolaptop mit Windows 7 64-bit. Die Hardware umfasst eine Intel Core 2 Duo CPU, 8 GB RAM, NVIDIA Quadro FX 570M Grafikkarte und ein Full HD Display. Installiert wurden Internet Explorer 9 Beta, Firefox 4 beta 6 und Google Chrome 7.0.530.0 (canary build).

Alle Browserfenster wurden einheitlich auf eine Größe von 1024x768 Pixel eingestellt. Auf den Bildern kann man sehr schön sehen, wieviel Platz davon eine Webseite tatsächlich einnehmen kann. Internet Explorer 9 bietet mit 1008x700 Pixel die größte Fläche gefolgt von Chrome mit 1008x679 und Firefox mit 1008x646.

Zum Testen verwendete ich natürlich den als Windows 7 Beta Hintergrundbild berühmt gewordenen Betta-Fisch, der ein neues Zuhause als Javascript und HTML Canvas Demo in FishIE Tank gefunden hat. Mit Speed Reading als zweiten Test prüfe ich HTML5 Canvas und HTML5 Audio. Da ich bei der Verwendung dieser Beispiele aber schon kritisiert wurde, dass sie für Unternehmen praxisfern wären, kommt mit WebVizbench als dritter Test eine ausgewachsene HTML5-Webanwendung zum Einsatz. WebVizBench visualisiert mit Hilfe von HTML5 ohne jedes Plug-In historische Playlisten aus einer Dekade des Radiosenders KEXP.org in Seattle. Neben den komfortablen Such- und Steuerungsmöglichkeiten kann man die Anwendung gleichzeitig als HTML5-Benchmark nutzen.

FishIE Tank

fishie-ie9 fishie-chrome fishie-firefox

Bei FishIE Tank erreichen alle Browser in der Standardeinstellung mit 20 Fischen mühelos eine Bildwiederholfrequenz von 60 FPS (englisch für Bilder pro Sekunde). Das ist das Maximum, was der Test erlaubt (Hintergründe dieser Begrenzung sind in Teds oben verlinktem Artikel beschrieben). Auch die Steigerung der Anzahl der Objekte ändert daran erst einmal nichts. Selbst bei 250 Objekten ist der Unterschied in der Bildwiederholfrequenz nur wenige Bilder pro Sekunde.

Ab 500 Objekten wird jedoch die Leistungsfähigkeit des Laptops langsam erreicht. Auf meiner Demohardware gibt bei 1.000 gleichzeitigen Objekten Internet Explorer 9 Beta leicht auf 45 FPS nach, während Google Chrome mit 27 FPS und Firefox mit 11 FPS deutlich langsamer werden.

Speed Reading

speedreading-ie9 speedreading-chrome speedreading-firefox

Speed Reading stellt Text wie die Anzeigetechnik auf Flughäfen und Bahnhöfen im Webbrowser dar. Dabei werden in allen Feldern immer alle Zeichen, Zahlen und Buchstaben rotiert, bis der gewünschte Text angezeigt wird. Im unteren Bereich sieht man aktuelle Daten während des Tests. Gemessen wird in Summe die Zeit, die der Browser zum Anzeigen des gesamten Textes benötigt.

Auch hier sind deutliche Unterschiede zu erkennen. Internet Explorer 9 Beta liegt hier mit 11s vor Google Chrome (28s) und Firefox (540s). Google Chrome fiel mir übrigens mit einer etwas unsauberen Darstellung auf – einige Zeichen wurden zwischendrin nicht ganz bis zum Ende rotiert.

WebVizBench

WebVizBench bietet zum Schluss den meiner Meinung nach bisher praxisrelevantesten Test. Hier kann man sehr schön sehen, was man in einer modernen Webanwendung heute realisieren kann. Die Effekte sind beeindruckend und super flüssig, wenn man sie mit modernen Browsern zu sehen bekommt. Die Auswertung gibt eine durchschnittliche Framerate an und summiert alle Teilergebnisse zu einem Gesamtpunktestand. Diesen Test habe ich in jeweils zweimal durchgeführt, um besonders die Unterschiede zwischen modernem, GPU-beschleunigtem Rendering und klassischem Softwarerendering aufzuzeigen.

Internet Explorer 9 Beta

webwizbench-ie9-hw webvizbench-ie9-sw

IE9 rennt auf meiner Demohardware mit 26,93 FPS allen davon und erzielt dabei 5.660 Punkte. Schaltet man die Hardwarebeschleunigung aus, merkt man den Effekt deutlich: Er fällt auf 7,29 FPS (3.120 Punkte).

Google Chrome 7.0.530.0

webvizbench-chrome-sw webvizbench-chrome-hw

Startet man Chrome mit den entsprechenden Parametern zum Einschalten der Hardwarebeschleunigung, rendert er auf meiner Demohardware nur 10,33 FPS und erzielt dabei 3.380 Punkte. Startet man ihn ganz normal, sieht man mit 10,14 FPS (3.180 Punkte) auch nur einen geringfügig schlechteren Unterschied. Entweder bin ich hier auf einen Bug in Chrome gestoßen oder wir sehen, wie auch mein Kollege Ted Johnson in dem oben verlinkten Artikel annimmt, wie sich die Unterschiede zwischen vollständiger und teilweiser Hardwarebeschleunigung in der Praxis auswirken.

Firefox 4 Beta 6

webvizbench-firefox-sw webvizbench-firefox-hw

Da Firefox keine Wiedergabe von H.264-Videos unterstützt, hatte ich mit deutlichen Vorteilen für Firefox gerechnet. Immerhin muss er im Benchmark einen wichtigen Teil nicht berechnen und sollte dadurch eigentlich einen Vorteil haben. Es kam aber ganz anders. Ich habe den Test mehrfach durchlaufen lassen und bin immer wieder auf das gleiche Ergebnis gekommen: Die bisherige Softwarerenderfunktion ist bei Firefox bisher effektiver. Während mit aktivierter Hardwarebeschleunigung lediglich 0,7 FPS und 2.710 Punkte möglich sind, erzielt Firefox nach dem Deaktivieren 1,5 FPS und 2.780 Punkte. Entweder bin ich hier ebenfalls auf einen Bug gestoßen oder der Overhead bei der teilweisen Optimierung ist möglicherweise zu groß. Joe Drew schrieb zu Mozillas Konzept im May dieses Jahres im Artikel Hardware accelerating Firefox:

“In order to get the sort of benefit that’s possible from GPU acceleration, a lot of analysis of the document needs to be done to identify the parts that need to be separated into their own layers. Some of this is relatively easy, like background images; other parts are much harder. Also, layers is designed to accelerate only portions of the web; this means that, in the common case, we will render most of the web page using software, then do only the hardest/slowest part using the GPU directly.”

Opera und Safari

webvizbench-opera-sw webvizbench-safari-sw

Um das Bild abzurunden, habe ich noch Opera und Safari außer der Reihe getestet. Beide verfügen (bisher?) nicht über Hardwarebeschleunigungsfunktionen und nutzen reine Softwarerenderer. Die Ergebnisse sind ebenfalls interessant: Opera erreicht 10,04 FPS und 3.670 Punkte, wobei hier ebenfalls keine H.264-Videos wiedergegeben werden, was natürlich einen Vorteil darstellt. Safari kommt auf 3,7 FPS und 2.910 Punkte.

Fazit

Die Implementierung von GPU-powered HTML5 ist keine einfache Aufgabe. Die drei meistverbreitesten Browser arbeiten zwar mit Hochdruck an dieser Baustelle, weisen aber derzeit deutliche Unterschiede auf. Microsoft bietet meiner Ansicht nach mit Internet Explorer 9 Beta bisher das überzeugendste Gesamtergebnis.

Comments
  • ...vergaß den link zu Demos

    sites.google.com/.../demos-gpu-acceleration-and-webgl

    leider halt nicht mit IE9

  • Allerdings funktioniert das nur in der frühesten Entwicklerversion: "Important: To try these demos, download an up-to-date canary or Chromium build. (Coming to the developer channel soon"

    Generell warnt zum Beispiel auch das W3C aktuell vor dem verfrühten Einsatz von sich noch in Entwicklung befindenden Webstandards:

    "Wir haben derzeit das Problem, dass es bereits viel Aufregung rund um HTML5 gibt, aber es ist noch zu früh, die Technik einzusetzen, da wir auf Kompatibilitätsprobleme zusteuern", erklärte Philippe Le Hegaret vom W3C gegenüber 'InfoWorld'. Derzeit kann nicht ausgeschlossen werden, dass noch größere Veränderungen an dem Standard vorgenommen werden.

    winfuture.de/news,58607.html

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment