„Native Applikationen sind performanter als Web-Apps!“ – das haben wir alle schon mal gehört aber was heißt das genau? Native Applikationen können auf die GPU des Gerätes zugreifen, und Web-Apps werden im Browser dargestellt, der somit auch das Rendering von diesen Webseiten übernimmt. Das führt zum Beispiel dazu, dass eine Animation die top– und left-Attribute nutzt, allgemein nicht so flüssig läuft wie eine Animation, die das -vendor-transform:translate3d-Attribut aus CSS3 verwendet – natürlich haben wir auch hier wieder das Problem mit den Browsern, deswegen auch das „-vendor“-Prefix.

Der Grund für die bessere beziehungweise flüssigere Animation ist, dass Attribute wie margin, padding, left, right und so weiter, innerhalb des Browsers, „Frame-by-Frame“ berechnet werden müssen. Ganz besonders problematisch äußert sich diese Vorgehensweise bei mehreren, gleichzieitg animierten, Elementen – wenn wir also Hardware-Acceleration einsetzen, dann wälzen wir die Arbeitslast vom Browser an den Grafikprozessor (GPU) ab.

Animationen, „Transitions“ und „Transforms“ werden per se nicht automatisch mit der GPU gerendert, sondern durch den Browser. Es wäre jetzt natürlich schön, wenn wir als Entwickler ein Attribut hätten, mit dem wir ein Rendering auch für Webprojekte im CSS aktivieren könnten. Ähnlich dem font-smoothing: antialiased mit dem wir das Rendering von Schrift und Texten steuern können. Das gibt es aber so nicht, alles was wir derzeit haben ist die Möglichkeit über einen „Hack“ – aber dazu später mehr. Nichts desto trotz könnt ihr mit der „Hardware-Acceleration“ bessere Performance, in fast allen Desktop-Browsern erreichen – sogar in einigen mobilen Browsern.

Derzeit unterstützten Firefox, Safari, Chrome, Opera und IE9+ diese Funktionalität, allerdings setzt eine Beschleunigung beim Rendering durch die GPU spezielle Befehle, innerhalb der CSS-Datei, voraus um auf ein DOM-Element angewandt werden zu können. 3D-Transformationen lösen immer eine „Hardware-Acceleration“ aus vorausgesetzt ihr nutzt, zum Beispiel, diesen Befehl:

transform: rotate3d( 0, 0, 0, 45deg );

anstelle von

transform: rotate( 45deg );

Manchmal kommt es bei dieser Methode zu sogenannten „Flickering“ während der Animation. Abhilfe schaffen hierbei diese zwei Attribute:

backface-visibility: hidden;
perspective: 1000;

Wobei backface-visibility definiert, ob ein Element sichtbar sein sollte, obwohl es nicht am Bildschirm angezeigt wird. Mit perspective könnt ihr die Entfernung zwischen dem Element und dem Viewport auf der Z-Achse in Pixeln angeben.

Beachtet aber, dass es sich hierbei um nicht standardisierte CSS-Attribute handelt. Und wie schon Dean Jackson (Apple) bereits 2010 sagte:

„Jede Transformation die eine 3D-Operation ausführt, wird eine Hardware-Beschleunigung bewirken, auch wenn die eigentliche Transformation sich im 2D-Raum bewegt, oder wenn die 3D-Transformation nichts tut (zum Beispiel bei translate3d(0,0,0)). Allerdings ist das nur derzeitiges Verhalten und dieses könnte sich in der Zukunft ändern (deswegen dokumentieren wir diese Funktion nicht oder fordern zur Anwendung auf). Aber diese Funktion ist sehr hilfreich und in einigen Situationen, kann sie die Rendering-Leistung siginifikant erhöhen.“

Jetzt ist es natürlich auch sinnvoll, die Hardware-Beschleunigung dort einzusetzen, wo sie am Meisten benötigt wird: bei Mobiltelefonen. Leider unterstützen anscheinend nur die WebKit-Browser ein Rendering über die GPU des Gerätes. Wie gesagt, handelt es sich hierbei um einen nicht standardisierten „Draft“ – aber was tut man als Entwickler nicht alles um Kundenwünsche wie: „Das muss dynamischer sein“ oder „Mein iPhone kann den Effekt X, wieso soll das nicht auf meiner Website funktionieren?“ zu erfüllen.

Weil CSS3, im direkten Vergleich, immer noch schneller ist – CSS3 wird nativ im Browser gerendert. Ja, der Nachteil wird zum Vorteil. Rich Bradshaw hat das auch in seiner Artikelserie zum Thema Animation mit CSS3 und Hardware-Acceleration anschaulich zur Schau gestellt. Mehr zu diesem Thema findet ihr übrigens hier. Das soll aber nicht heißen, dass ihr auf JavaScript verzichten sollt. Letztendlich kommt es, wie immer, auf das spezifische Projekt, an.

Angesichts der Tatsache, dass sich das Web ständig weiterentwickelt: Die neueren Versionen von Google Chrome setzen teilweise schon automatisch auf ein GPU-Rendering bei opacity und auch bei 2D-Transformationen, kann man sich als Entwickler nicht immer auf diese nicht-standadisierten Methoden verlassen, weil nicht gewährleistet werden kann, ob ein zukünftiger Browser in Kombination mit einem Gerät ein Attribut unterstütz oder nicht – und ob es dabei nicht zu Darstellungsfehlern kommen könnte. Als Entwickler hat man auch die Aufgabe, diese Informationen an den Kunden weiterzugeben, damit Ärger auf beiden Seiten erspart bleibt.

Setzt ihr die „Hardware-Acceleration“ von CSS3 ein?