Bereit für die nächste Generation von Webinhalten
Ich bin Chris Harrelson, Engineering Lead für das Rendering (Umwandlung von HTML und CSS in Pixel) in Blink. Ich bin seit über acht Jahren tief in der Rendering-Leistung im Web tätig, mit dem persönlichen Ziel, alles in meiner Macht Stehende zu tun, um eine hervorragende UX im Web schneller, einfacher und zuverlässiger zu machen. Ich freue mich, dass wir Ihnen mitteilen können, was wir in dieser Zeit zur Entwicklung einer neuen, hochmodernen Chromium-Rendering-Engine-Architektur getan haben. Dafür war eine harte Arbeit nötig, und ich hoffe, Sie hören viel Spaß!
2021 werden wir weitgehend den Entwurf, Bau und den Versand dieser Architektur abschließen. Nennen wir es RenderingNG, da es sich um eine Rendering-Architektur der nächsten Generation handelt, die die bisherige Leistung deutlich übertrifft. RenderingNG wird seit mindestens acht Jahren durchgeführt und ist die gemeinsame Arbeit zahlreicher Chromium-Entwickler. Es bietet ein enormes Potenzial für die nächste Generation von schnellen, flüssigen, zuverlässigen, responsiven und interaktiven Webinhalten. Sie ist außerdem eine Basis, die meiner Meinung nach einen neuen Mindeststandard für alle Web-Rendering-Engines definiert, auf die sich Entwickler stützen können.
Dieser Blogbeitrag ist der erste in einer Reihe, in dem wir erklären, was wir entwickelt haben, warum wir es entwickelt haben und wie es funktioniert. In diesem ersten Post beginne ich mit:
- Unser Nordsternziel.
- Die Erfolgspyramide: Prinzipien, die uns bei unserer Arbeit zugrunde liegen, und Beispiele für diese Prinzipien in der Praxis.
- Die Funktionen und Möglichkeiten, die RenderingNG ermöglicht.
- Ein allgemeiner Überblick über die wichtigsten Projektkomponenten von RenderingNG.
Nordstern
Das Nordsternziel für RenderingNG ist, dass die Implementierung der Browser-Engine und die vielfältigen Rendering-APIs kein einschränkender Faktor für die UX im Web sein sollten.
Sie müssen sich keine Gedanken darüber machen, ob Browserfehler dazu führen, dass Funktionen unzuverlässig werden oder das Rendering Ihrer Website beeinträchtigt wird.
Es sollte keine mysteriösen Performance-Cliffs geben. Außerdem sollten Sie fehlende integrierte Funktionen nicht umgehen müssen.
Es sollte einfach funktionieren.
Ich glaube, RenderingNG ist ein großer Schritt in Richtung dieses Nordsternziels. Vor RenderingNG konnten und konnten wir Rendering-Features hinzufügen und die Leistung verbessern. Wir hatten jedoch Schwierigkeiten, diese Funktionen für Entwickler zuverlässig zu machen, und es gab viele Leistungsschwächen. Jetzt haben wir eine Architektur, die systematisch viele dieser Probleme beseitigt und auch erweiterte Features freischaltet, die zuvor nicht als machbar galten. Die DSGVO hat folgenden Zweck:
- Hat zuverlässige Kernfunktionen für verschiedene Plattformen, Geräte und Betriebssysteme.
- Die Leistung des Geräts ist vorhersehbar und zuverlässig.
- Maximiert die Nutzung von Hardwarefunktionen (Kerne, GPU, Bildschirmauflösung, Aktualisierungsraten, Low-Level-Raster-APIs).
- Führt nur die Arbeiten aus, die für die Anzeige sichtbarer Inhalte erforderlich sind
- Bietet integrierte Unterstützung für gängige visuelle Design-, Animations- und Interaktionsdesignmuster.
- Stellt Entwickler-APIs zur einfachen Verwaltung der Renderingkosten bereit.
- Stellt Rendering-Pipeline-Erweiterungspunkte für Entwickler-Add-Ins bereit.
- Optimiert alle Inhalte: HTML, CSS, 2D Canvas, 3D-Canvas, Bilder, Videos und Schriftarten.
Vergleich mit anderen Browser-Rendering-Engines
Gecko und Webkit haben auch die meisten der in diesen Blogposts beschriebenen Architekturfunktionen implementiert und in einigen Fällen sogar vor Chromium hinzugefügt. Was toll ist! Jeder Browser, der schneller und zuverlässiger wird, ist Grund zum Feiern und hat echte Wirkung. Das ultimative Ziel besteht jedoch darin, die Basisversion für alle Browser zu verbessern, damit Entwickler sich darauf verlassen können.
Die Erfolgspyramide
Meine Philosophie ist, dass Erfolg zuerst das Ergebnis von Zuverlässigkeit, dann skalierbarer Leistung und schließlich Erweiterbarkeit ist.
Wie bei einer echten Pyramide bietet jede Ebene eine notwendigerweise solide Grundlage für die darüber liegende Ebene.
Zuverlässigkeit
Wenn umfassende und komplexe User Experiences möglich sein sollen, brauchen wir als Erstes eine absolut solide Plattform. Die Kernfunktionen und -grundlagen müssen korrekt funktionieren und im Laufe der Zeit funktionieren. Genauso wichtig ist es, dass sich diese Funktionen gut zusammensetzen und keine seltsamen Grenzfälle oder Programmfehler auftreten.
Aus diesem Grund ist Zuverlässigkeit der wichtigste Aspekt von RenderingNG. Zuverlässigkeit ist das Ergebnis guter Tests, hochwertiger Feedbackschleifen, Metriken und Softwaredesignmuster.
Um ein Gefühl dafür zu bekommen, wie wichtig Zuverlässigkeit ist, haben wir die meiste Zeit der letzten acht Jahre damit verbracht. Zuerst haben wir uns ein tiefgreifendes Wissen über das System aufgebaut. Wir lernten aus Fehlerberichten, wo die Schwachstellen liegen, und beseitigen sie. Außerdem haben wir umfassende Tests durchgeführt und uns mit den Leistungsanforderungen von Websites und den Einschränkungen der Chromium-Leistung vertraut gemacht. Anschließend haben wir wichtige Designmuster und Datenstrukturen sorgfältig und inkrementell entworfen und eingeführt. Erst dann waren wir in der Lage, Primitive der nächsten Generation für responsives Design, Skalierbarkeit und Anpassung des Renderings hinzuzufügen.
Das bedeutet nicht, dass im Laufe der Zeit in Chromium nichts verbessert wurde. Tatsächlich ist das Gegenteil der Fall! In diesen Jahren ergaben sich eine stetige und nachhaltige Steigerung der Zuverlässigkeit und Leistung, da wir jede Verbesserung schrittweise refaktoriert und eingeführt haben.
Tests und Messwerte
In den letzten acht Jahren haben wir Zehntausende Einheiten-, Leistungs- und Integrationstests hinzugefügt. Darüber hinaus haben wir umfassende Messwerte entwickelt, die viele Aspekte des Renderings von Chromium messen – in lokalen Tests, in Leistungsmaßstäben und in der Praxis auf echten Websites mit echten Nutzern und Geräten.
Aber egal, wie großartig RenderingNG (oder das Rendering-Modul eines anderen Browsers) ist, es wird immer noch schwierig sein, eine Lösung für das Web zu entwickeln, wenn viele Fehler oder Unterschiede im Verhalten der einzelnen Browser auftreten. Um dieses Problem zu beheben, maximieren wir auch die Verwendung von Webplattform-Tests. Mit jedem dieser Tests wird ein Nutzungsmuster der Webplattform überprüft, das alle Browser bestehen sollten. Außerdem beobachten wir genau, welche Messwerte für mehr Tests im Laufe der Zeit und die Erhöhung der Kernkompatibilität erforderlich sind.
Web Platform-Tests sind eine gemeinsame Anstrengung. Die Chromium-Entwickler haben beispielsweise nur etwa 10% der gesamten WPT-Tests für CSS-Funktionen hinzugefügt. Den Rest tragen andere Browseranbieter, unabhängige Mitwirkende und Autoren von Spezifikationen bei. Zum Ausbau des interoperablen Webs braucht man ein ganzes Dorf!
Gute Software-Designmuster
Die zuverlässige Bereitstellung von qualitativ hochwertiger Software ist wiederum viel einfacher, wenn der Code leicht verständlich und so konzipiert ist, dass die Wahrscheinlichkeit von Fehlern minimiert wird. In den nachfolgenden Blogposts werden wir noch viel mehr über das Softwaredesign von RenderingNG berichten.
Skalierbare Leistung
Eine hervorragende Leistung – unabhängig von Geschwindigkeit, Arbeitsspeicher und Energieverbrauch – ist der nächste wichtige Aspekt von RenderingNG. Wir möchten, dass Interaktionen mit allen Websites reibungslos und responsiv sind, ohne die Stabilität des Geräts zu beeinträchtigen.
Wir möchten jedoch nicht nur Leistung, sondern auch skalierbare Leistung – eine Architektur, die auf Low-End- und High-End-Maschinen sowie auf verschiedenen Betriebssystemplattformen zuverlässig funktioniert. Ich bezeichne dies „Hochskalieren“, wobei ich alle Möglichkeiten der Hardware ausnutzen und verkleinern kann, um die Effizienz zu maximieren und bei Bedarf die Systemlast zu verringern.
Dafür mussten Caching, Leistungsisolierung und GPU-Hardwarebeschleunigung maximal genutzt werden. Betrachten wir jede einzeln. Und um es konkret zu formulieren: Überlegen wir, wie jede von ihnen zur Leistung einer extrem wichtigen Interaktion auf Webseiten beiträgt: dem Scrollen.
Caching
In einer dynamischen, interaktiven UI-Plattform wie dem Web ist das Caching die wichtigste Möglichkeit, die Leistung erheblich zu verbessern. Die bekannteste Art des Cachings in einem Browser ist der HTTP-Cache. Beim Rendering gibt es jedoch auch viele Caches. Der wichtigste Cache für das Scrollen sind im Cache gespeicherte GPU-Texturen und Anzeigelisten, die ein extrem schnelles Scrollen ermöglichen, den Akku schonen und auf verschiedenen Geräten gut funktionieren.
Caching verbessert die Akkulaufzeit und die Animations-Framerate für das Scrollen. Noch wichtiger ist jedoch, dass es die Leistungsisolierung vom Hauptthread blockiert.
Leistungsisolation
Bei modernen Desktop-Computern müssen Sie sich keine Sorgen machen, dass Anwendungen im Hintergrund die Arbeit verlangsamen. Der Grund dafür ist das präemptive Multitasking, das wiederum eine Form der Leistungsisolation darstellt: Es wird sichergestellt, dass unabhängige Aufgaben sich nicht gegenseitig verlangsamen.
Das beste Beispiel für Leistungsisolation ist das Scrollen im Web. Selbst bei Websites mit vielen langsamen JavaScript-Inhalten kann das Scrollen sehr reibungslos verlaufen, da er in einem anderen Thread ausgeführt wird, der nicht vom JavaScript- und Layout-Thread abhängig ist. Wir investieren viel Arbeit in RenderingNG, um sicherzustellen, dass alle möglichen Scrollvorgänge als Threads dargestellt werden. Das geht über das Caching hinaus, das weit über die reine Anzeigeliste hinausgeht und komplexere Situationen bietet. Beispiele hierfür sind Code zur Darstellung fester und fixierter Elemente, passive Ereignis-Listener und hochwertiges Text-Rendering.
GPU-Beschleunigung
Eine GPU macht die Generierung von Pixeln und das Zeichnen auf dem Bildschirm wesentlich schneller – in vielen Fällen kann jedes Pixel parallel zu jedem anderen Pixel gezeichnet werden, was zu einer enormen Geschwindigkeitssteigerung führt. Eine wichtige Komponente von RenderingNG ist ein GPU-Raster, das überall gezeichnet werden kann. Dabei wird die GPU auf allen Plattformen und Geräten verwendet, um das Rendern und Animieren von Webinhalten zu beschleunigen. Dies ist besonders wichtig bei Low-End- oder sehr High-End-Geräten, die oft eine viel leistungsstärkere GPU als andere Teile des Geräts haben.
Erweiterbarkeit: Die richtigen Tools für Ihre Aufgaben
Sobald wir über Zuverlässigkeit und skalierbare Leistung verfügen, können wir auf einer Reihe von Tools aufbauen, mit denen Entwickler die integrierten Bestandteile von HTML, CSS und Canvas auf eine Weise erweitern können, ohne dabei auf hart erarbeitete Leistung und Zuverlässigkeit verzichten zu müssen.
Dazu gehören integrierte und JavaScript-basierte APIs für erweiterte Anwendungsfälle wie responsives Design, progressives Rendering, flüssiges Design und Reaktionsschnelligkeit sowie Threaded-Rendering.
Die folgenden offenen Web-APIs, die von Chromium unterstützt werden, wurden durch RenderingNG ermöglicht und galten bisher als nicht durchführbar.
Sie wurden alle mit offenen Spezifikationen und in Zusammenarbeit mit offenen Webpartnern entwickelt, also mit Entwicklern anderer Browser, Experten und Webentwickler. In den nachfolgenden Blogposts werden wir jeden dieser Bereiche näher betrachten und erläutern, wie sie mit RenderingNG möglich sind.
- Inhaltssichtbarkeit: Websites können Renderingaufgaben für nicht sichtbare Inhalte einfach vermeiden und Cache-Rendering für nicht angezeigte einseitige Anwendungsansichten im Cache speichern.
- OffscreenCanvas: Damit kann das Canvas-Rendering (2D Canvas API und WebGL) in einem eigenen Thread ausgeführt werden, um eine zuverlässig hervorragende Leistung zu erzielen. Dieses Projekt ist auch ein weiterer wichtiger Meilenstein für das Web: Es ist die allererste Web-API, mit der JavaScript (oder WebAssembly!) ein Webseitendokument aus mehreren Threads rendern kann.
- Containerabfragen: Ermöglicht das responsive Layout einer einzelnen Komponente und hebt die Blockierung einer ganzen Reihe von Plug-and-Play-Komponenten auf (derzeit eine experimentelle Implementierung).
- Ursprungsisolierung: Websites können eine stärkere Leistungsisolation zwischen iFrames aktivieren.
- Farb-Worklets außerhalb des Hauptthreads: Gibt Entwicklern die Möglichkeit, die Darstellung von Elementen zu erweitern, und zwar mit Code, der auf dem Compositor-Thread ausgeführt wird.
Zusätzlich zu expliziten Web-APIs ermöglicht uns RenderingNG, mehrere wichtige „automatische Funktionen“ bereitzustellen, von denen alle Websites profitieren:
- Website-Isolierung: Damit werden ursprungsübergreifende iFrames in verschiedene CPU-Prozesse eingefügt, um die Sicherheit und Leistungsisolierung zu verbessern.
- Vulkan, D3D12 und Metal: nutzt untergeordnete APIs, die GPUs effizienter als OpenGL nutzen.
- Weitere zusammengesetzte Animationen: SVG, Hintergrundfarbe
Wir freuen uns außerdem auf folgende neue Funktionen, die durch RenderingNG freigeschaltet werden können:
- Durch Scrollen verknüpfte Animationen:
- Ausgeblendetes, aber suchbares und zugängliches DOM.
- Übergänge gemeinsam verwendeter Elemente:
- Benutzerdefiniertes Layout:
- Compositing außerhalb des Hauptthreads; Entkopplung von Threading und Compositing
Wichtige Projekte, aus denen RenderingNG besteht
Im Folgenden finden Sie eine Liste der wichtigsten Projekte in RenderingNG. In den folgenden Blogposts wird jeder einzelne Beitrag ausführlicher behandelt.
CompositeAfterPaint
Beseitigt Zusammensetzung von Stil, Layout und Farbe, was wesentlich verbesserte Zuverlässigkeit und vorhersehbare Leistung, erhöhten Durchsatz und weniger Arbeitsspeicher ohne Leistungseinbußen ermöglicht. Das Projekt wurde 2014 gestartet und wird noch in diesem Jahr abgeschlossen.
| Jahr | Fortschritt |
|---|---|
| 2015 | Anzeigelisten für Schiffe. |
| 2017 | Neue Entwertung versenden. |
| 2018 | Versandeigentumsbäume, Teil 1: |
| 2019 | Versandeigentumsbäume, Teil 2: |
| 2021 | Versand des Projekts abgeschlossen. |
LayoutNG
Alle Layoutalgorithmen wurden komplett neu geschrieben, um die Zuverlässigkeit und die Leistung zu verbessern. Sie begann 2016 und soll in diesem Jahr fertig sein.
| Jahr | Fortschritt |
|---|---|
| 2019 | Blockabfluss des Schiffs. |
| 2020 | Versand flexibel, Bearbeitung. |
| 2021 | Versenden Sie alles andere. |
BlinkNG
Eine systematische Bereinigung und Refaktorierung der Blink-Rendering-Engine in sauber getrennte Pipelinephasen. Dies ermöglicht ein besseres Caching, eine höhere Zuverlässigkeit und Funktionen für das erneute oder verzögerte Rendering, z. B. für die Sichtbarkeit von Inhalten und Containerabfragen. Das Programm begann 2014 und wird seitdem schrittweise verbessert. Er wird 2021 abgeschlossen.
GPU-Beschleunigung überall
Eine langfristige Einführung der GPU-Rasterung, des Zeichnens und der Animation auf allen Plattformen. Die GPU-Beschleunigung sorgt für eine enorme Beschleunigung der meisten Inhalte, da jedes Pixel parallel verarbeitet werden kann. Es ist auch eine effektive Methode zur Verbesserung der Leistung auf Low-End-Geräten, die in der Regel immer noch eine GPU haben. Es begann 2014 und wurde 2020 fertiggestellt.
| Jahr | Fortschritt |
|---|---|
| 2014 | Canvas-Unterstützung. Versand mit Opt-in-Inhalten unter Android |
| 2016 | Für Mac versenden |
| 2017 | GPU wird bei über 60% der Android-Seitenaufrufe verwendet. |
| 2018 | Bereit für Windows, ChromeOS und Android Go. |
| 2019 | GPU-Rasterung mit Threads |
| 2020 | Restliche Android-Inhalte versenden. |
Scrollen, Animationen und Decodierung durch Threads
Eine langfristige Untersuchung, bei der alle Scroll-, Layout-induzierenden Animationen und Bilddecodierungen aus dem Hauptthread entfernt werden. Sie wurde 2011 gestartet und ist noch lange nicht am Ende.
| Jahr | Fortschritt |
|---|---|
| 2011 | Erste Unterstützung für Scroll- und Animationsthreads. |
| 2015 | Zusammenfügen von Ebenen. |
| 2016 | Universelles Scrollen durch Überlauf. |
| 2017 | Bild wird im Compositor-Thread decodiert. |
| 2018 | Bildanimationen im Compositor-Thread. |
| 2020 | Setze immer eine feste Position zusammen. |
| 2021 | Transformationsanimationen in Prozent, SVG-Animationen. |
Visualisierung
Ein zentraler Raster- und Zeichenprozess für Chromium, der den Durchsatz erhöht, den Arbeitsspeicher optimiert und die optimale Nutzung der Hardwarefunktionen ermöglicht. Es bietet auch andere Vorteile, die für Webentwickler, aber sehr sichtbar für Nutzer sind, z. B. die Blockierung der Website-Isolierung aufheben und die Rendering-Pipeline vom Rendern der Browser-UI entkoppeln. Es begann 2016 und wird 2021 abgeschlossen sein.
| Jahr | Fortschritt |
|---|---|
| 2018 | OOP-R wird für Android, Mac und Windows ausgeliefert. |
| 2019 | OOP-D versandt OOP-R wird überall versandt (außer Canvas). SkiaRenderer wird unter Linux ausgeliefert. |
| 2020 | SkiaRenderer wird für Windows und Android ausgeliefert. Vulkan für Android verfügbar. |
| 2021 | SkiaRenderer wird für Mac (und bald auch für ChromeOS) veröffentlicht. |
Definitionen der Begriffe in der obigen Tabelle:
- OOP-D
- Out-of-Process-Display-Compositor Der Display-Zusammensetzungsprozess ist die gleiche Art von Aktivität wie ein Betriebssystem-Compositor. „Out of Process“ bedeutet, dass dies im Visualisierungsprozess und nicht im Renderingprozess der Webseite oder im Browser-UI-Prozess geschieht.
- OOP-R
- Out-of-Process-Raster. Das Raster wandelt Anzeigelisten in Pixel um. „Out of Process“ bedeutet, dass dies im Visualisierungsprozess und nicht beim Rendering der Webseite erfolgt.
- SkiaRenderer
- Eine neue Display-Compositor-Implementierung, die die Ausführung auf einer Reihe verschiedener zugrunde liegender GPU-APIs wie Vulkan, D3D12 oder Metal unterstützt.
Beschleunigtes Canvas-Rendering mit Threads
In diesem Projekt wurden die architektonischen Bausteine eingesetzt, die OffscreenCanvas ermöglicht haben. Das Projekt wurde 2015 gestartet und endet im Jahr 2021.
| Jahr | Fortschritt |
|---|---|
| 2018 | Versand außerhalb des Bildschirms. |
| 2019 | ImageBitmapRenderingContext versenden. |
| 2021 | Versand OOP-R. |
VideoNG
Ein langfristiges Ziel, eine effiziente, zuverlässige und qualitativ hochwertige Videowiedergabe im Web bereitzustellen.
| Jahr | Fortschritt |
|---|---|
| 2014 | Einführung eines Mojo-basierten Rendering-Frameworks. |
| 2015 | Project Butter und Video-Overlays wurden für ein flüssigeres Video-Rendering versendet. |
| 2016 | Versand einheitlicher Pipelines für Android- und Desktop-Decodierung und Rendering |
| 2017 | HDR und farbkorrigiertes Videorendering wurden ausgeliefert. |
| 2018 | Versendete Pipeline zur Videodecodierung auf Mojo-Basis. |
| 2019 | Versendete Pipeline für oberflächenbasierte Videorendering. |
| 2021 | Unterstützung für das Rendern geschützter Inhalte in 4K unter ChromeOS. |
Definitionen der Begriffe in der obigen Tabelle:
- Mojo
- IPC-Subsystem der nächsten Generation für Chromium
- Plattform/Oberfläche
- Ein Konzept, das Teil des Visualisierungs-Projektdesigns ist.
Fazit
Ich freue mich über die Geschwindigkeit, mit der sich das Rendering im Web und in Chromium verbessert. Ich erwarte, dass das Tempo in den kommenden Jahren weiter zunehmen wird, da wir auf der soliden Grundlage von RenderingNG aufbauen können.
Wir werden in Zukunft noch viele weitere Beiträge veröffentlichen, in denen die neue Architektur, ihre Entstehung und ihre Funktionsweise noch ausführlicher beschrieben werden.
Gerätefoto von Eirik Solheim auf Unsplash
Illustrationen von Una Kravets.