Quantum: Mozilla kündigt Next-Generation-Engine für Firefox an
Mozilla hat Quantum angekündigt, die Browserengine der nächsten Generation, welche Firefox ab Ende 2017 antreiben und die Performance auf ein ganz neues Niveau heben soll.
Die Multiprozess-Architektur Electrolysis, kurz: e10s, war zuletzt Mozillas Top-Priorität für Firefox und erreicht nach und nach mehr Nutzer. Es handelt sich dabei nicht nur um den größten Umbau von Firefox, seit es den Mozilla-Browser gibt, es bildet auch das Fundament für weitere große Änderungen, die Mozilla plant.
Dies schließt auch das nun von Mozilla angekündigte Projekt Quantum mit ein. Darunter fallen Mozillas Bestrebungen, eine Browserengine der nächsten Generation zu entwickeln. Erste Resultate sollen ab Ende 2017 in Firefox ausgeliefert werden, die Ziel-Plattformen sind Microsoft Windows, Apple macOS, Linux sowie Android. Außerdem hofft Mozilla, eines Tages auch auf Apple iOS Quantum einsetzen zu können.
Mozilla erhofft sich von Quantum einen derartigen Performance-Sprung, dass sich die gesamte Web-Experience, verglichen mit dem Stand heutiger Engines, anders anfühlen soll: Webseiten sollen schneller laden, das Scrolling noch sanfter sein, Animationen und interaktive Apps sollen verzögerungsfrei antworten und mit noch mehr Content bei gleichbleibend hoher Framerate umgehen können. Wichtige Inhalte sollen automatisch die höchste Priorität beim Rendering zugewiesen bekommen. Möglich soll dies durch die Ausnutzung moderner Hardware, die Parallelisierung von Aufgaben sowie Auslagerung von Aufgaben an die Grafikkarte werden.
Die Beziehung zwischen Servo und Quantum
Unweigerlich stellt sich die Frage nach der Beziehung zum Servo-Projekt. Unter dem Namen Servo wird eine unabhängige Engine entwickelt, deren Community über Mozilla hinausgeht und deren Hauptsponsor Mozilla ist. Servo wird von Grund auf neu entwickelt, basiert auf keiner anderen Engine und ist entsprechend noch weit davon entfernt, als vollwertige Engine in einem Browser genutzt werden zu können. Servo ist damit vor allem ein Forschungsprojekt.
Quantum hingegen basiert auf der aktuellen Firefox-Engine Gecko und ersetzt wesentliche Teile von Gecko durch Neu-Implementierungen, einschließlich welcher aus dem Servo-Projekt. Daraus ergibt sich, dass wie in Servo auch wesentliche Teile von Quantum in der Programmiersprache Rust entwickelt sein werden.
Für das Servo-Projekt stellt Quantum einen wesentlichen Meilenstein dar, da grundlegende Konzepte und Entwicklungen von Servo der letzten Jahre damit ihre Praxistauglichkeit beweisen und mehrere hundert Millionen Nutzer erreichen werden. Gleichzeitig wird erwartet, dass dadurch auch die Servo-Community weiter wächst.
Durch die stückweise Integration von Servo-Komponenten in Firefox müssen Nutzer nicht noch mehrere Jahre warten, um signifikante Performance- sowie Stabilitätsverbesserungen zu erhalten, die sich durch Mozillas Next-Generation-Engine ergeben.
Quantum im Detail
Mit Quantum überdenkt Mozilla fundamentale Aspekte dessen, wie eine Browserengine funktioniert. Grundlegende Dinge, beispielsweise wie CSS-Styles angewendet oder DOM-Operationen ausgeführt werden, werden neu durchdacht und implementiert.
Das Mozilla Wiki listet verschiedene Komponenten, welche im Rahmen von Quantum intitial Komponenten aus Gecko ersetzen sollen.
Wer die Entwicklung von Firefox genauer beobachtet, sieht bereits seit ein paar Monaten Teile von Quantum CSS, auch Stylo genannt, in Firefox landen. Es handelt sich dabei um die „CSS-Engine“ von Servo, welche im Gegensatz zu der von Firefox Parallelisierung beherrscht.
Auch den Quantum Render kennt man aus Servo, dort unter dem Namen WebRender. WebRender arbeitet im Grunde wie eine Spiele-Engine, ist aber für das Rendering von Web-Content optimiert. Dabei profitiert die Engine nicht nur von mehreren Prozessor-Kernen, vor allem die Grafikkarte wird sehr viel stärker als bisher eingebunden. WebRender konnte Anfang des Jahres in einer Demo eines Google-Mitarbeiters bereits eine beeindruckende Performance vorweisen und soll als Grafik-Backend von Firefox verwendet werden.
Der Quantum Compositor verschiebt Geckos Compositor-Code in einen eigenen Prozess. Da Grafiktreiber eine der Hauptquellen für Firefox-Abstürze sind, wird durch die Auslagerung in einen eigenen Prozess erwartet, dass Firefox deutlich stabiler wird.
Quantum DOM soll Gecko reaktionsfreudiger machen, vor allem mit vielen geöffneten Hintergrundtabs. Darüber kann in einem eigenen Blog-Artikel (engl.) detaillieter nachgelesen werden.
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.
Ich warte immer noch auf e10, das wäre schon toll wenn ich das bald nutzen könnte :).
Lange wird's nicht mehr dauern. Je nachdem, was bei dir das Ausschlusskriterium ist, ist es vielleicht sogar schon in Firefox 50 soweit. 😉
Wird der Code denn in einem Repo zusammen gepflegt(mit Geckoanpassungen als extra Bereich) oder nimmt man sich das Servo-Teilprojekt und entwickelt das dann als Fork quasi in Gecko weiter ggf. mit dem etwas unglücklichen Phänomen des Hin-und-Her-Portierens einzelner Features? Ist es letztlich Ziel Gecko und Servo irgendwann mal, wenn man alle Teile "portiert" hat, deckungsgleich zu machen, wobei dann Servo als "Forschungsprojekt" eine Art "unstable" Entwicklungszweig ist, in dem dann natürlich auch immer Teilbereiche sind, die immer weiter voran sind.
Und wie genau geht die Eingliederung auf Interface-Ebene von statten? Es war ja oft davon zu lesen, dass Gecko und Firefox recht eng verzahnt sind bzw. der Nutzen durch andere Programme bei Gecko bzgl. der Schnittstellen nicht so im Fokus war. Allein aus diesem Aspekt heraus soll die Nutzung der Chrome-Engine über das CEF für andere Projekte embeded interessanter/einfacher gewesen sein.
Ob das nun wirklich so ist, mag ich nicht beurteilen. Aber aus der Perspektive heraus wollte man bei Servo ja dieses Framework auch unterstützen. Entsprechend habe ich Servo als die eigenständige Version wahrgenommen, auf die letztlich auch bei Firefox(als ein(besonderer) unter vielen) alles hinausläuft. Wird eine Komponente als "reif" wahrgenommen, wird Firefox dann an der Stelle entflechtet und die Schnittstellen an Servo angepasst. Firefox nutzt teils Gecko, teils Servo. Jetzt klingt es ja so, als könnten die Servo-Schnittstellen evtl. auf das alte "Gecko"-Design umgemodelt werden, soweit möglich.
Letztlich wird es aber wohl sowohl in Gecko als auch in Servo einen Überbau geben, der die einzelnen Komponenten managed, die eigentlichen externen Schnittstellen bereitstellt und der mit dem Rest von Firefox(oder anderen) kommuniziert, sodass es so gar keine direkte Kommunikation der Komponenten wie Quantum CSS mit (Rest-)Firefox gibt? Entsprechend muss es in Gecko integriert werden, solange man keinen kompletten Break hin zu Servo macht (was nicht in kleinen Schritten möglich wäre). Gibt es evtl. Diagramme der entsprechenden Architektur?
Hoffentlich wird meine Fragestellung noch deutlich 😉
Aber wenn ich den Mozilla Wiki-Eintrag richtig verstehe, dann ist Quantum doch quasi genau die Servo-Rendering-Engine (Quantum CSS und Quantum Render werden beide als reine Servo-Komponenten beschrieben) plus Optimierungen an der nicht-rendrelevanten Browserarchitekur, oder nicht?
Mir ist die Abgrenzung tatsächlich noch nicht ganz klar. Was von Gecko (außer des Namens) bleibt denn dann?
@Julian:
Das Style-System ist Code, den sich Servo und Gecko teilen. Gecko benötigt natürlich diverse Anpassungen, um das Style-System verwenden zu können.
In welchem Repository der Style-System-Code gepflegt und wie er dann in den Gecko-Code integriert wird, ist am Ende nur eine Release-Engineering-Frage.
Das kann man so als Ziel nicht formulieren, da Servo dazu zu unkomplett ist und man nur planen kann, in Gecko zu integrieren, was in Servo existiert und nicht noch in den Sternen steht. Man kann aber sagen, dass das Ziel ist, langfristig noch einiges mehr aus Servo zu importieren als das, was im Artikel genannt wird.
Das Interface bleibt hiervon vollkommen unberührt. Die Oberfläche ist in XUL geschrieben, Servo unterstützt kein XUL, Gecko aber schon. Und solange Gecko dafür zuständig ist und Gecko XUL beherrscht, gibt es hier keinen Einfluss.
Vereinfacht gesagt kann man das vielleicht sagen, dass Firefox teils Gecko, teils Servo nutzt, wobei korrekter wäre, dass Komponenten aus Servo in Gecko integriert werden, da Firefox schlecht von zwei halben Engines betrieben werden kann, am Ende gibt es eine Engine.
Quantum CSS ist so gesehen eine Komponente, wie es sie bereits in Gecko gibt und diese wird ganz einfach ersetzt. Wie du schon richtig sagst, ansonsten müsste man einen kompletten Break hin zu Servo machen und das ist in diesem Zeitrahmen nicht möglich.
Vielleicht wird Servo ja eines Tages die Firefox-Engine sein, aber das ist jetzt noch nicht absehbar, in jedem Fall wird auch das einfacher, wenn ein Teil eh schon "Servo" ist. Quantum bringt gute Entwicklungen aus Servo ganz einfach früher in Firefox.
Vielleicht, mir aber nicht bekannt. 😉
@foobar:
Es sind einzelne Komponenten aus Servo. Servo als Ganzes wäre noch nicht in der Lage, Firefox zu betreiben. Alleine schon, weil Servo beispielsweise kein XUL unterstützt, es bräuchte dann ja auch eine neue Theme-Implementierung und zahlreiche Add-ons würden nicht mehr funktionieren. Das liegt ferner in der Zukunft.
Diesbezüglich gibt es doch einen ganzen Abschnitt "Die Beziehung zwischen Servo und Quantum". 😉
Das sind ja alles höchst wünschenswerte Änderungen, allerdings befürchte ich, dass man im Großen und Ganzen 2017 erst zu Chromium und Co. aufschließen wird – ein "Quantensprung" also eher für Firefox, nicht für das Web. Ein Äquivalent zum Compositor bspw. hat Chromium soweit ich weiß schon seit längerer Zeit.
Auch wirklich anspruchsvolle Web-Apps überfordern Firefox gerne noch, wer mal versucht hat ein komplexes CRM mit Firefox zu nutzen, wird wissen was ich meine.
Anderes geht natürlich deutlich darüber hinaus, wie die Pläne für das Rendering, aber die Konkurrenz schläft ja auch nicht. Ich hoffe Mozilla wird ein erfolgreiches 2017 haben – mein Herz schlägt immer noch für Firefox, da Mozilla meiner Meinung nach der mit Abstand beste Browserhersteller für die User ist.
Aufschließen ist sicher auch eine Sache der Definition, in welchem Bereich. Sowohl wenn es um Leistung als auch wenn es um Funktionen geht, ist ja weder Firefox noch Chrome der grundsätzlich beste Browser, da beide Browser in manchen Dingen besser als der jeweils andere sind. Und wenn es um Marktanteile geht, wird das alleine Mozilla vermutlich wenig helfen. Da geht leider viel mehr über Marketing und Verknüpfung mit Diensten. Nur mit Qualität ist es leider sehr schwierig mit Google noch mitzuhalten. Aber Qualität bleibt natürlich eine wichtige Voraussetzung. 😉
Hast du dir denn die Demo des Google (!)-Mitarbeiters mal angesehen? Ich betone extra Google-Mitarbeiter, weil dadurch eine geschönte Demo ausgeschlossen werden kann. Vor mehr als einem halben Jahr hat Servo in dieser Demo Chrome bereits in den Schatten gestellt. Ein Quantensprung ist das definitiv nicht nur für Firefox, sondern für das Web – natürlich gemessen an heutigen Maßstäben. Nichts anderes ist ja auch die Aussage von Mozilla. Man weiß nicht, was Google Ende 2017 präsentieren wird, die werden ja auch nicht schlafen, wie du selbst etwas später in deinem Kommentar schreibst. Und ein Vergleich mit Chrome/Chromium Ende 2017 ist jetzt noch nicht möglich. Man kann nur sagen, dass es ein Quantensprung gegenüber dem werden wird, was wir Stand heute haben. Sei es in Firefox oder in Chrome.
Hast du ein Beispiel für eine App, die Firefox überfordert? Ich bin über die Aussage überrascht, weil Mozilla ja schon eine Art Vorreiter ist, wenn es um komplexe Anwendungen im Browser geht, Stichwort asm.js und die Portierung bekannter Spiele-Engines für den Browser.
Grundsätzlich halte ich es für einen Fehler des Webentwicklers, wenn eine Web-App nicht performant in allen Browsern läuft, denn performante Apps sind definitiv browserübergreifend möglich.
Ich hoffe das auch. Selbst, wenn man Chrome/Chromium viel besser findet, also kein besonderes Herz für Mozilla schlagen hat, auch Google braucht Konkurrenz, davon profitieren alle. 😉
Ja, die habe ich mit Freuden angeschaut, als du sie damals hier verlinkt hast. Und ja, DAS wäre definitiv ein Quantensprung, Hardwarebeschleunigung ist ja nach wie vor ein sehr problematisches Thema in Browsern.
Youtube benutze ich momentan in Firefox, weil Chrome ständig Frames droppt und Fehlermeldungen in der GPU-Page dazu bringt. Auf Skylake-iGPUs ist VPx-Decoding momentan generell deaktiviert.
Aber ich denke bis man diese Performance in Verbindung mit dem momentanten Firefox-Kern haben wird, wird es noch ein weiter Weg.
Wir haben in der Firma zuletzt einige Web-CRMs getestet und die Lösung von SAP war in Chrome deutlich performanter. Andererseits verwendet das für einige Funktionen noch Microsoft Silverlight – das sagt wahrscheinlich schon einiges über den Zustand des Systems aus…
Dennoch scheint Chrome mit sowas besser klarzukommen, unabhängig von der deutlich verbesserten Multi-Tab-Performance von Firefox mit e10s.
Ich hoffe nur Firefox wird bei sinkendem Marktanteil nicht komplett abgehängt was die Kompatibilität zu Websiten angeht. Sowas sorgt wahrscheinlich schneller für Userschwund als alles andere – andererseits sind Webentwickler bei dem Marktanteil von Firefox, gerade im mobilen Bereich, nicht mehr gezwungen unbedingt auf Firefox zu achten. Eine gefährliche Kombination, auch wenn Firefox natürlich gerade in Deutschland immer noch ein relevanter Browser ist.
Das ist natürlich sehr interessant, weil man vom Google-Browser beim Google-Portal eigentlich erst einmal die besten Ergebnisse erwartet. Leider bin ich bei Chrome nicht informiert, was bekannte Probleme betrifft, sprich ob in absehbarer Zeit mit einer Verbesserung zu rechnen ist. :/
Definitiv, leider. 😉
Durchaus möglich, leider habe ich keine Möglichkeit, mir von diesem Beispiel selbst ein Bild zu machen. Ich hoffe nur, dass die Verwendung von Silverlight optional ist, denn ab Firefox 52 (Mainstream) beziehungsweise im Release danach (ESR) ist Schluss mit Silverlight, das unterstützt Firefox dann gar nicht mehr.
Das wird auch nicht dadurch besser, dass Firefox mittlerweile Webkit-Eigenschaften emulieren kann, sprich wenn Entwickler nur -webkit-Versionen implementieren. Leider ist das mittlerweile notwendig, damit Firefox-Nutzer nicht total verloren sind, gerade bei der Nutzung des Smartphones, das reduziert gleichzeitig aber natürlich noch mehr die Wahrscheinlichkeit, dass Entwickler mehr Rücksicht auf Nicht-Webkit-Browser nehmen. Die Webkit-Dominanz (nicht nur durch Google, auch durch Apple) ist ein echtes Problem.
Ich würde eher sagen diese properitären Prefixe allgemein sind ein Problem.
Nicht wirklich allgemein, weil das Problem nur dadurch entsteht, dass gefühlt 99,9 Prozent der genutzten Smartphone-Browser Webkit-Browser sind. Die Dominanz der einen Engine ist es, welche verursacht, dass die Mehrheit der Webentwickler andere Engines ignoriert. Die Browserhersteller sind eh schon dazu übergegangen, die Verwendung von Vendor-Präfixes zu vermeiden. Das ändert aber leider überhaupt nichts daran, was bereits da ist. Und aus Kompatibilitätsgründen ist es für keinen Browser möglich, die Unterstützung zu entfernen.
Ist Blink noch so nah an Webkit, dass es da untereinander keine Probleme gibt?
Blink versteht nach wie vor -webkit- als Vendor-Präfix, genauso übrigens wie Microsoft Edge und Apple Safari sowieso. Firefox war bis vor kurzem also der einzige Browser, der das nicht verstanden hat…