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

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.

Um 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

 

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

 

 

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

 

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

 

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

 

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

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

• Anonymous
  January 01, 2003
  Hallo Arian, schau mal in meine IE9 FAQ (blogs.technet.com/.../internet-explorer-9-beta-faq.aspx) unter "Wie kann ich Feedback über eine Funktion von Internet Explorer 9 Beta geben?" VG, Daniel

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  @Alex: Irgendwas scheinst Du verpaßt zu haben. Internet Explorer 9 wird von uns vor allem unter dem Gesichtspunkt Standardkonformität entwickelt. BTW: ACID3 ist kein aussagefähiger Test auf Webstandards und beinhaltet Dinge, die zur Zeit schon wieder veraltet sind. @Diego: Vielen Dank für das Feedback. Du kannst auch die Feedbackfunktion von IE9 nutzen, um Deine Vorschläge dem Team direkt zur Verfügung zu stellen. Einfach das Extras-icon anklicken und "Feedback senden" wählen. VG, Daniel

• Anonymous
  September 22, 2010
  The comment has been removed

• Anonymous
  September 23, 2010
  Das sieht ja schon mal sehr gut aus. Mal sehen was sich bis zur Final noch tut. Ein Punkt den ich allerdings noch ansprechen wollte ist, dass ich die Verwaltung der Favoriten nicht ganz optimal finde. Dadurch dass die Favoritenleiste weggefallen ist, wird es umso wichtiger wie die Favoritenverwaltung gegenüber IE8 zu verbessern. Oder aber es gibt die Möglichkeit die Favoritenleiste wieder manuell einzublenden. Welche Verbesserungen könnte ich mir vorstellen?

• Einen einfachen Button zum speichern des Favorits (wie in der Favoritenleiste) ohne Abfrage nach Name und Speicherort. Vielleicht könnte man das über die Optionen konfigurierbar machen, dass Favoriten beim klick auf den Button automatisch in einen bestimmten Ordner (z.B. zu sortieren) gespeichert werden.
• Einfachere Verwaltung z.B. hinter jedem Ordner ein kleines Icon zum Speichern oder so etwas. Wenn zu jedem Favoriten der "Speicher-Dialog" erscheint und mühevoll der Ornder aus dem DropDown Feld ausgewählt werden muss, finde ich das etwas zu aufwändig.
• Die Favoritenliste sollte sich besser in die GUI integrieren Das nur so als kleines Feedback zur Favoritenfunktion. Gruß Philipp

• Anonymous
  September 28, 2010
  Baut doch mal den IE9 für Linux - dann würde ich ihn testen!

• Anonymous
  September 29, 2010
  Hallo Daniel, Ich teste seit einiger Zeit IE9 und wollte ein Feedback zu dieser Software geben. Ich finde jedoch nicht den passenden Ort dazu. Weisst du wo ich mich melden soll, um Feedback zu geben. MIr sind da einige Sachen aufgefallen. Gruss Arian

• Anonymous
  October 02, 2010
  Sehr interessant. Kostenpflichtige Software (weil man dafür Windows Braucht) versucht sich auf irgendeine weise durchzusetzen. Ihr habt doch sogar Geld und seid trotzdem so schlecht (acid-tests und allgemein einhalten von standards), warum?

• Anonymous
  October 03, 2010
  The comment has been removed