Bereit für die nächste Generation von Webinhalten
RenderingNG ist eine Rendering-Architektur der nächsten Generation, die eine deutlich bessere Leistung als die bisherigen bietet. RenderingNG wurde über mehr als acht Jahre aufgebaut und repräsentiert die kollektive Arbeit vieler engagierter Chromium-Entwickler. Es birgt ein enormes Potenzial für schnelle, flüssige, zuverlässige, responsive und interaktive Webinhalte.
Hier erfährst du, was wir entwickelt haben, warum wir es entwickelt haben und wie es funktioniert.
Tor zum Nordstern
Das Hauptziel für RenderingNG ist, dass die Implementierung der Browser-Engine und die Vielfalt der Rendering-APIs kein einschränkender Faktor für die Nutzerfreundlichkeit im Web sein sollten.
Ihr müsst euch keine Gedanken über Browserfehler machen, die dazu führen, dass Funktionen unzuverlässig werden oder das Rendering eurer Website beeinträchtigen.
Es sollte keine mysteriösen Performance-Klippen geben. Außerdem sollten Sie keine fehlenden integrierten Funktionen umgehen müssen.
Es sollte einfach funktionieren.
RenderingNG ist ein großer Schritt auf dem Weg zu diesem Nordsternziel. Vor dem RenderingNG konnten wir Rendering-Features hinzufügen und die Leistung verbessern. Allerdings hatten wir Schwierigkeiten, diese Funktionen für Entwickler zuverlässig zu machen, und es gab viele Leistungsklippen. Jetzt haben wir eine Architektur, die viele dieser Probleme systematisch überwindet und gleichzeitig erweiterte Features freisetzt, die zuvor nicht als realisierbar galten. Die DSGVO hat folgenden Zweck:
- Hat funktionstüchtige Hauptfunktionen für verschiedene Kombinationen aus Plattform, Gerät und Betriebssystemen.
- Hat eine vorhersehbare und zuverlässige Leistung.
- Maximiert die Nutzung von Hardwarefunktionen (Kerne, GPU, Bildschirmauflösung, Aktualisierungsraten, Low-Level-Raster-APIs).
- Es werden nur die Arbeiten ausgeführt, die zur Anzeige sichtbarer Inhalte erforderlich sind.
- Integrierte Unterstützung für gängige visuelle Design-, Animations- und Interaktionsdesignmuster.
- Stellt Entwickler-APIs zur einfachen Verwaltung der Rendering-Kosten bereit.
- Stellt Pipeline-Erweiterungspunkte für das Rendern von Entwickler-Add-ins bereit.
- Optimiert alle Inhalte – HTML, CSS, 2D-Canvas, 3D-Canvas, Bilder, Videos und Schriftarten.
Vergleich mit anderen Rendering-Modulen für Browser
Gecko und Webkit haben außerdem die meisten der in diesen Blogposts beschriebenen Architekturfunktionen implementiert und in einigen Fällen sogar schon vor Chromium hinzugefügt.
Jeder Browser, der schneller und zuverlässiger wird, ist Grund zum Feiern und hat echte Auswirkungen. Das letztendliche Ziel ist es, die Baseline für alle Browser zu verbessern, damit sich Entwickler darauf verlassen können.
Die Erfolgspyramide
Meine Philosophie ist, dass Erfolg das Ergebnis ist, wenn zuerst Zuverlässigkeit, dann skalierbare Leistung und schließlich Erweiterbarkeit erreicht werden.
Wie bei einer realen Pyramide stellt jede Ebene eine notwendige solide Grundlage für die obige Ebene dar.
Zuverlässigkeit
Wenn eine umfassende und komplexe Nutzererfahrung überhaupt möglich sein soll, brauchen wir eine solide Plattform. Die Kernfunktionen und die Grundlagen müssen einwandfrei funktionieren und im Laufe der Zeit weiterhin funktionieren. Genauso wichtig ist es, dass sich diese Funktionen gut zusammensetzen und keine seltsamen Grenzfälle oder Programmfehler haben.
Aus diesem Grund ist Zuverlässigkeit der wichtigste Teil von RenderingNG. Zuverlässigkeit ist das Ergebnis guter Tests, Qualitäts-Feedbackschleifen, Metriken und Softwaredesignmustern.
Um zu verdeutlichen, wie wichtig Zuverlässigkeit ist, haben wir in den letzten acht Jahren nur diesen Teil erarbeitet. Zunächst haben wir ein tiefgreifendes Wissen über das System aufgebaut. Wir haben aus Fehlerberichten gelernt, wo die Schwachstellen waren, und beheben diese, führen umfassende Tests durch und verstehen die Leistungsanforderungen von Websites und die Einschränkungen der Chromium-Leistung. Anschließend haben wir sorgfältig und schrittweise wichtige Designmuster und Datenstrukturen entworfen und eingeführt. Erst dann konnten wir wirklich Primitive der nächsten Generation für responsives Webdesign, die Skalierbarkeit und die Anpassung des Renderings hinzufügen.
Das bedeutet nicht, dass Chromium im Laufe dieser Zeit nicht verbessert wurde. Tatsächlich ist das Gegenteil der Fall. In diesen Jahren kam es zu einem stetigen und anhaltenden Anstieg der Zuverlässigkeit und Leistung, da wir jede Verbesserung Schritt für Schritt 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, mit denen Sie viele Aspekte des Renderings von Chromium in lokalen Tests, in Leistungsvergleichen und bei der Nutzung von realen Websites mit echten Nutzern und Geräten messen können.
Aber egal wie gut RenderingNG (oder das Rendering-Modul eines anderen Browsers) ist – wenn viele Fehler oder Unterschiede im Verhalten der Browser auftreten, ist die Entwicklung für das Web nicht einfach. Um dies zu erreichen, maximieren wir auch die Nutzung von Webplattform-Tests. Mit jedem dieser Tests wird ein Nutzungsmuster der Webplattform verifiziert, das alle Browser erfüllen sollten. Wir überwachen auch die Messwerte, um im Laufe der Zeit mehr Tests zu bestehen und die Kernkompatibilität zu erhöhen.
Webplattform-Tests sind eine gemeinsame Initiative. Beispielsweise haben Chromium-Entwickler nur etwa 10% der gesamten WPT-Tests für Funktionen von CSS hinzugefügt. Den Rest tragen andere Browseranbieter, unabhängige Beitragende und Spezifikationsautoren bei. Es braucht ein ganzes Dorf, um das interoperable Web zu schaffen!
Gute Softwaredesignmuster
Die zuverlässige Bereitstellung qualitativ hochwertiger Software ist wiederum viel einfacher, wenn der Code leicht zu verstehen und so konzipiert ist, dass die Wahrscheinlichkeit von Fehlern minimiert wird. In den folgenden Blogposts können wir noch viel mehr zum Softwaredesign von RenderingNG sagen.
Skalierbare Leistung
Der zweitwichtigste Aspekt von RenderingNG ist das Erzielen einer hervorragenden Leistung in den Bereichen Geschwindigkeit, Arbeitsspeicher und Energieverbrauch. Wir möchten, dass die Interaktionen mit allen Websites reibungslos und responsiv sind, ohne auf die Stabilität des Geräts verzichten zu müssen.
Wir wollen jedoch nicht nur Leistung, sondern auch skalierbare Leistung – eine Architektur, die auf Low-End- und High-End-Maschinen und auf verschiedenen Betriebssystemplattformen zuverlässig funktioniert. Dies nenne ich das Hochskalieren, also das Nutzen all dessen, was das Hardwaregerät erreichen kann, und das Herunterskalieren, um bei Bedarf die Effizienz zu maximieren und die Nachfrage an das System zu reduzieren.
Dazu mussten wir Caching, Leistungsisolierung und GPU-Hardwarebeschleunigung maximal nutzen. Betrachten wir die einzelnen Optionen nacheinander. Sehen wir uns an, wie jede von ihnen zur Leistung einer extrem wichtigen Interaktion auf Webseiten beiträgt: Scrollen.
Caching
In einer dynamischen, interaktiven UI-Plattform wie dem Web ist Caching der wichtigste Weg, um die Leistung erheblich zu verbessern. Die bekannteste Art des Cachings in einem Browser ist der HTTP-Cache. Das Rendering umfasst jedoch auch viele Caches. Der wichtigste Cache für das Scrollen sind zwischengespeicherte GPU-Texturen und Anzeigelisten. Diese ermöglichen ein extrem schnelles Scrollen und minimieren gleichzeitig den Akkuverbrauch und funktionieren auf einer Vielzahl von Geräten gut.
Caching verbessert die Akkulaufzeit und die Framerate der Animation beim Scrollen, aber noch wichtiger ist, dass es die Leistungsisolation vom Hauptthread aufhebt.
Leistungsisolierung
Bei modernen Desktop-Computern brauchen Sie sich keine Sorgen zu machen, dass Hintergrundanwendungen die Ausführung verlangsamen. Das liegt an dem präventiven Multitasking, das wiederum eine Form der Leistungsisolierung darstellt. Dadurch wird sichergestellt, dass unabhängige Aufgaben sich gegenseitig nicht verlangsamen.
Das beste Beispiel für Leistungsisolation im Web ist das Scrollen. Selbst auf Websites mit viel langsamem JavaScript kann das Scrollen sehr flüssig sein, da es in einem anderen Thread läuft, der nicht vom JavaScript- und Layout-Thread abhängig ist. In RenderingNG haben wir viel Aufwand betrieben, um dafür zu sorgen, dass bei jedem möglichen Scrollen ein Thread vorhanden ist, und zwar durch Caching, das weit über eine Anzeigeliste hinausgeht, aber auch komplexere Situationen. Beispiele hierfür sind Code zur Darstellung von fixierten und fixierten Elementen, passiven Ereignis-Listenern und hochwertigem Textrendering.
GPU-Beschleunigung
Mit einer GPU wird das Generieren von Pixeln und das Zeichnen auf dem Bildschirm erheblich beschleunigt. 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 GPU-Raster, mit dem überall gezeichnet werden kann. Dabei wird die GPU auf allen Plattformen und Geräten genutzt, um das Rendern und Animieren von Webinhalten zu beschleunigen. Dies ist besonders auf Low-End- oder sehr High-End-Geräten wichtig, die oft eine viel leistungsfähigere GPU haben als andere Teile des Geräts.
Erweiterbarkeit: Die richtigen Tools für die Aufgabe
Sobald wir Zuverlässigkeit und skalierbare Leistung haben, können wir auf einer Reihe von Tools aufbauen, mit denen Entwickler die integrierten Bestandteile von HTML, CSS und Canvas erweitern können, ohne auf diese Leistung und Zuverlässigkeit zu verzichten.
Dazu gehören integrierte und mit JavaScript gefährdete APIs für erweiterte Anwendungsfälle in den Bereichen responsives Design, progressives Rendering, flüssiges und responsives Rendering sowie Thread-Rendering.
Die folgenden von Chromium unterstützten offenen Web-APIs wurden durch RenderingNG ermöglicht und bisher als nicht durchführbar eingestuft.
Alle wurden mit offenen Spezifikationen und in Zusammenarbeit mit offenen Webpartnern entwickelt – Entwicklern anderer Browser, Experten und Webentwicklern. In den folgenden Blogposts werden wir jeden dieser Punkte genauer untersuchen und erläutern, wie RenderingNG sie ermöglicht.
- content- visibility: Damit können Websites problemlos das Rendern von Arbeit für nicht sichtbare Inhalte vermeiden und das Cache-Rendering für derzeit nicht gezeigte Single-Page-Anwendungsaufrufe vermeiden.
- OffscreenCanvas: Ermöglicht die Ausführung von Canvas-Rendering (sowohl die 2D Canvas API als auch WebGL) in einem eigenen Thread, um eine zuverlässige hervorragende Leistung zu erzielen. Dieses Projekt stellt auch einen weiteren wichtigen Meilenstein für das Web dar. Es ist die allererste Web-API, die es JavaScript (oder WebAssembly!) ermöglicht, ein einzelnes Webseitendokument aus mehreren Threads zu rendern.
- Containerabfragen: Ermöglicht das responsive Layout einer einzelnen Komponente, sodass eine ganze Reihe von Plug-and-Play-Komponenten blockiert wird (derzeit eine experimentelle Implementierung).
- Ursprungsisolation: Damit können Websites eine stärkere Leistungsisolation zwischen iFrames aktivieren.
- Paint Worklets außerhalb des Hauptthreads: Bietet Entwicklern die Möglichkeit, die Darstellung von Elementen mit Code zu erweitern, der auf dem zusammengesetzten Thread ausgeführt wird.
Neben expliziten Web-APIs konnten wir dank RenderingNG mehrere sehr wichtige "automatische Funktionen" bereitstellen, von denen alle Websites profitieren:
- Website-Isolierung: Dabei werden ursprungsübergreifende iFrames in verschiedene CPU-Prozesse eingebunden, um die Sicherheit und Leistungsisolation zu verbessern.
- Vulkan, D3D12 und Metal: Nutzt die Vorteile untergeordneter APIs, die GPUs effizienter nutzen als OpenGL.
- Weitere zusammengesetzte Animationen: SVG, Hintergrundfarbe.
Weitere neue Funktionen, die durch RenderingNG freigeschaltet werden:
- Über Scrollverknüpfungen verknüpfte Animationen:
- Verborgenes, aber durchsuchbares und zugängliches DOM:
- Übergänge gemeinsam genutzter Elemente:
- Benutzerdefiniertes Layout:
- Zusammensetzung außerhalb des Hauptthreads; Threading und Compositing entkoppeln.
Wichtige Projekte, aus denen RenderingNG besteht
Hier ist eine Liste der wichtigsten Projekte in RenderingNG.
CompositeAfterPaint
CompositeAfterPaint trennt die Zusammensetzung von Stil, Layout und Paint. Dies ermöglicht eine deutlich verbesserte Zuverlässigkeit und vorhersehbare Leistung, einen höheren Durchsatz und eine geringere Speichernutzung ohne Leistungseinbußen.
| Jahr | Fortschritt |
|---|---|
| 2015 | Anzeigelisten für Schiffe |
| 2017 | Neue Entwertung versenden. |
| 2018 | Bäume an Schiffseigentum Teil 1. |
| 2019 | Bäume für Schiffseigentumsbäume Teil 2. |
| 2021 | Der Versand des Projekts wurde abgeschlossen. |
LayoutNG
Eine von Grund auf neu geschriebene Layout-Algorithmen für eine stark verbesserte Zuverlässigkeit und vorhersehbare Leistung.
Weitere Informationen zu LayoutNG
| Jahr | Fortschritt |
|---|---|
| 2019 | Blockfluss. |
| 2020 | Schiff unterwegs, bearbeiten. |
| 2021 | Alles andere versenden. |
BlinkNG
Wir haben die Blink-Rendering-Engine refaktoriert und in sauber getrennte Pipelinephasen aufgeteilt. Dies ermöglicht ein besseres Caching, höhere Zuverlässigkeit und Funktionen wie die Sichtbarkeit von Inhalten und Containerabfragen, die wieder eintreten oder später gerendert werden.
GPU-Beschleunigung überall
Die GPU-Beschleunigung bietet eine enorme Beschleunigung für die 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 tendenziell noch eine GPU haben.
| Jahr | Fortschritt |
|---|---|
| 2014 | Canvas-Unterstützung Wird mit Opt-in-Inhalten auf Android-Geräten ausgeliefert. |
| 2016 | Mit Mac versenden |
| 2017 | GPU wird für über 60% der Android-Seitenaufrufe verwendet. |
| 2018 | Mit Windows, ChromeOS und Android Go kompatibel. |
| 2019 | GPU-Rasterung mit Threads |
| 2020 | Verbleibende Android-Inhalte versenden. |
Threadbasiertes Scrollen, Animationen und Decodierung
Langfristiges Unterfangen, alle scrollbaren, nicht layoutgesteuerten Animationen und der Bilddecodierung aus dem Hauptthread zu verschieben Sie ist fortlaufend.
| Jahr | Fortschritt |
|---|---|
| 2011 | Anfängliche Unterstützung von Scrolling und Animation mit Threads. |
| 2015 | Zusammenfügen von Ebenen |
| 2016 | Universelles Überlauf-Scrollen. |
| 2017 | Bild wird im Compositor-Thread decodiert. |
| 2018 | Bildanimationen im zusammengesetzten Thread. |
| 2020 | Immer eine feste Position setzen. |
| 2021 | Animationen für prozentuale Transformation, SVG-Animationen. |
Visualisierung
Ein zentraler Raster- und Zeichenprozess für Chromium, der den Durchsatz erhöht, den Speicher optimiert und die optimale Nutzung von Hardwarefunktionen ermöglicht. Es hat andere Vorteile, die für Webentwickler weniger sichtbar, aber für Nutzer sehr sichtbar sind, z. B. das Aufheben der Blockierung der Website-Isolierung und die Entkopplung der Rendering-Pipeline vom Rendering der Browser-UI.
| Jahr | Fortschritt |
|---|---|
| 2018 | OOP-R wurde für Android, Mac und Windows ausgeliefert. |
| 2019 | OOP-D versandt. OOP-R wurde überall versendet (außer Canvas). SkiaRenderer wurde für Linux veröffentlicht. |
| 2020 | SkiaRenderer wurde für Windows und Android veröffentlicht. Vulkan wurde auf Android-Geräten veröffentlicht. |
| 2021 | SkiaRenderer wurde für Mac (und demnächst auch für ChromeOS) ausgeliefert. |
Definitionen der Begriffe in der Tabelle oben:
- OOP-D
- Out-of-Process-Display-Compositor. Die Erstellung von Displayanzeigen erfolgt auf dieselbe Art und Weise wie ein Betriebssystem-Compositor. „Out of Process“ bedeutet, dass der Vorgang im Visualisierungsprozess erfolgt, nicht im Renderprozess der Webseite oder im Browser-UI-Prozess.
- OOP-R
- Out-of-Process-Raster. Raster konvertiert Displaylisten in Pixel. „Out-of-Process“ bedeutet, dass der Vorgang im Visualisierungsprozess erfolgt und nicht im Renderprozess der Webseite.
- 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.
Thread-basiertes und beschleunigtes Canvas-Rendering
Dieses Projekt hat OffscreenCanvas ermöglicht.
| Jahr | Fortschritt |
|---|---|
| 2018 | Versenden Sie OffscreenCanvas. |
| 2019 | ImageBitmapRenderingContext versenden. |
| 2021 | Versenden Sie OOP-R. |
VideoNG
VideoNG ist eine langfristige Aufgabe, um eine effiziente, zuverlässige und qualitativ hochwertige Videowiedergabe im Web zu ermöglichen.
| Jahr | Fortschritt |
|---|---|
| 2014 | Einführung eines Mojo-basierten Rendering-Frameworks |
| 2015 | Project Butter und Video-Overlays für ein flüssigeres Videorendering wurden versandt. |
| 2016 | Bereitstellung einheitlicher Decodierungs- und Rendering-Pipelines für Android und Desktop |
| 2017 | HDR- und farbkorrigiertes Videorendering wurde geliefert. |
| 2018 | Versand der Mojo-basierten Videodecodierungspipeline |
| 2019 | Ausgeführte oberflächenbasierte Video-Rendering-Pipeline |
| 2021 | Unterstützung für das Rendering geschützter Inhalte mit 4K unter ChromeOS wurde bereitgestellt. |
Definitionen der Begriffe in der Tabelle oben:
- Mojo
- IPC-Subsystem der nächsten Generation für Chromium
- Plattform/Oberfläche
- Ein Konzept, das Teil des Viz-Projektdesigns ist.
Illustrationen von Una Kravets.