„Azure“ – Neue Grafik-API soll Firefox beschleunigen
Eines der Projekte, an denen Mozilla momentan arbeitet, hört auf den Namen „Azure“, eine neue Grafik-API, welche Cairo teilweise ersetzen und die Darstellung von Webseiten beschleunigen soll. In den letzten Wochen hat man ein Proof-of-Concept-Direct2D-Backend erstellt, welches den Leistungsgewinn bestätigte, weswegen man dies nun für das HTML5-Canvas-Element noch im zweiten Quartal umsetzen möchte. Einen konkreten Zeitplan für das gesamte Projekt gibt es bisher nicht.
Wie funktioniert das Rendering: Die Rendering-Engine Gecko schaut, wie die Webseite aufgebaut ist und teilt diese in unabhängige Layer auf. Jeder dieser Layer wird von der 2D-Grafik-API namens „Cairo“ gezeichnet. Dieser Vorgang kann, beispielsweise durch Direct2D, durch die Hardware beschleunigt werden. Hinterher werden die Layer entweder durch Cairo oder durch eine 3D-API wie OpenGL oder Direct3D wieder zusammengesetzt und die Webseite auf dem Bildschirm angezeigt.
Ein Nachteil von Cairo ist, dass Cairo mit Festkommazahlen arbeitet, während beispielsweise Direct2D mit Fließkommazahlen arbeitet. Bei der Hardwarebeschleunigung durch Direct2D müssen dann immer Konvertierungen stattfinden, welche Rechenzeit kosten. Desweiteren ist Cairo zustandsbehaftet, was bedeutet, dass jeder Funktionsaufruf vom Ergebnis der vorherigen Funktion abhängt. Bekommt Cairo nun Daten von einer ebenso zustandsbehafteten API, müssen wieder Konvertierungen stattfinden. Ein weiteres Problem ist, dass Cairo Funktionen unterstützt, welche allerdings von Direct2D nicht unterstützt werden, weshalb hier durch die Software emuliert werden muss.
Mit Azure möchte man nun eine solche zustandslose API entwickeln, welche anstelle von Cairo zum Einsatz kommen soll, und orientiert sich dabei an Direct2D. Umwandlungen sollen weitestgehend vermieden werden, Hardwarebeschleunigung auf allen Plattformen in gleicher Weise zur Verfügung gestellt werden. Mac OS X wird ebenfalls von Azure profitieren, da durch die Zustandslosigkeit ebenfalls Umrechnungen, in dem Falle für das Quartz-Backend, wegfallen. Für die Fälle, in welche keine Backends implementiert sind, wird es einen Fallback auf Cairo geben, welches dann wie bisher eingesetzt wird. Außerdem wird Cairo weiterhin für die Druckansicht zum Einsatz kommen und wenn keine Hardwarebeschleunigung aktiviert ist. Ist die 2D-API fertig, soll Azure auch auf die 3D-APIs OpenGL und Direct3D portiert werden, womit dann auch Windows XP, Linux sowie mobile Geräte von der Hardwarebeschleunigung profitieren können.
Azure soll den beschleunigten Seitenaufbau auch unterstützen, wenn der Browser in mehrere Prozesse aufgeteilt ist, was mittelfristig bei Firefox der Fall sein wird und unter dem Codenamen „Electrolysis“ läuft. Eine notwendige Bedingung hierfür ist Azure jedoch nicht.
Sören Hentzschel ist Webentwickler aus Salzburg. Auf soeren-hentzschel.at informiert er umfassend über Neuigkeiten zu Mozilla. Außerdem ist er Betreiber von camp-firefox.de, der ersten Anlaufstelle im deutschsprachigen Raum für Firefox-Probleme aller Art. Weitere Projekte sind firefox.agenedia.com, firefoxosdevices.org sowie sozone.de.
Wenn es denn mal einen objektiven, brauchbaren Test für die „Browserspeed“ geben würde. Bei Sunspider z.B. kann man (ich) auf Grund der Zahlen nur so „Pi x Daumen“ was sagen:
„IE9, Chrome, Opera sind da ähnlich schnell, der FF is was langsamer“
„Das ist ein flotter Desktop-PC, das ist ein lahmes Netbook“
Und einige andere „Tests“ sind von Browserherstellern „inspiriert“ – da kannste auch ´nen VW-Händler fragen, ob der Astra besser ist als der Golf…
Und: im privaten Umfeld gibt es Vorlieben, da nutzt die Speed „gaanix“. Der IE fällt eh hinten runter, den will ich nicht. Und für mein Surfverhalten ist die höhere Speed von Chrome vs. Fox auch nicht entscheidend – der Fox ist mir flott genug.
Ob Sunspider, v8, Kraken und wie sie alle heißen – Benchmarks liefern sowieso immer nur einen Anhaltspunkt. Und die beziehen sich dazu auch noch ausschließlich auf die JavaScript-Performance. Man wird daraus nie ableiten können, welcher Browser der schnellste ist, man darf es nur auch nicht ignorieren, weil es eine Tendenz zeigt. Was ich damit sagen will: Einen objektiven Test hierfür kann es nicht geben. Man kann nur versuchen, Test-Suiten zu entwickeln, die realen Anforderungen nahe kommen. Der JavaScript-Experte Douglas Crockford hat jetzt mal einen anderen Ansatz verfolgt und gemessen, wie lange die Browser brauchen, um mit JSLint die jslint.js zu verarbeiten – dort schnitt Chrome am Schlechtesten ab, ist auch überraschend, wenn man mit den bekannten Benchmarks vergleicht. Es hängt einfach sehr von der Definition ab, was man als realitätsnahe Anwendung betrachtet. In der Summe arbeitet jede Applikation anders und jeder kann irgendwo seine Vor- und Nachteile haben.
Was das hier wiederum unterscheidet, ist dass es hier nicht um die JavaScript-Performance geht, sondern um die Rendering-Performance. Und das ist ein hochkomplexes Thema, da es hier viele Fälle gibt. Es hängt von der Hardware ab, von den Treibern, vom Betriebssystem, von der Betriebssystemversion, ist die Hardwarebeschleunigung aktiv oder nicht aktiv. Vergleichstabellen gibt es dazu hier noch nicht, weil das Projekt ganz am Anfang noch steht, man hat ja erst ein Proof-of-Concept. Wichtig ist vor allem die gefühlte Geschwindigkeit und auch wenn Firefox nicht langsam ist, es ist begrüßenswert, wenn es schneller geht, da Webanwendungen immer komplexer werden.
Ich möchte mal ein Beispiel bringen: Zoomen auf Google Maps. Mit der Hardwarebeschleunigung, die Firefox auf Vista / 7 bringt, ist der Performance-Unterschied gigantisch groß, das merkt man auch als normaler Anwender sofort. Diese Art der Beschleunigung ist auf Windows XP beispielsweise aber nicht möglich. Und Azure soll die gleichen Vorteile auch auf dieses System bringen. Und für mobile Geräte wird das natürlich auch ganz, ganz wichtig.
Recht hast du – „Zeiten“ sind ein komplexes Thema – nicht nur beim Comp. Ich habe ja mal länger Zeitstudium in der Industrie gemacht (bevor du fragst: ja, ich war der mit der Stoppuhr in der Hand, und nicht der, der „gewerkelt“ hat…)
Mit den Unterschieden ist das auch so eine Sache: DIE fallen hauptsächlich dann auf, wenn man öfter wechselt. Also, wenn jemand dauernd mit/an anderen Comps zu tun hat. Das ist bei mir z.B. wenig der Fall. Ich vergleiche also meine Hardware – und ich hab nun mal nicht 50 Comps, sondern 3. Und 3,5 OS: Win7 64+32, Snow Leopard, Ubuntu 11.04.
Trotzdem fällt das natürlich auch da schon auf, und Schlüsse ziehen kann ich auch. Das der FF mit 30 Adds vielleicht auf einem Netbook nicht in 3/4 Sekunden steht, das kann ich mir denken. Und wenn der FF mal 1,5 GB RAM braucht, dann nehm ich das eben zur Kenntnis – es bleibt noch genug übrig. Aber was machen müssen/sollten die da schon.
Das ganze ist vor allem aus einem Grund wichtig: durch die jetzige Konkurrenz kann sich kein Browser mehr ausruhen, wie einst der IE.
Ein Nachteil von Cairo ist, dass Cairo mit Festkommazahlen arbeitet, während beispielsweise Direct2D mit Fixkommazahlen arbeitet.
Da verwechstelst du aber was. „Fest“ und „Fix“ bedeutet das gleiche. Soweit ich weiß, arbeitet Direct2D mit Fließkommazahlen.
Jupp, auf den selben Fehler wurde ich auch schon per E-Mail hingewiesen, da hab ich geschlafen. Im Falle von Direct2D waren natürlich, wie du richtig sagst, Fließkommazahlen gemeint. Ist nun korrigiert. Vielen Dank. 🙂