RenderingNG-Architektur

Chris Harrelson

Hier erfahren Sie, wie die Komponenten von RenderingNG aufgebaut sind und von der Rendering-Pipeline durchlaufen werden.

Beginnend auf der obersten Ebene sind die Aufgaben des Renderings:

1. Rendern Sie Inhalte auf dem Bildschirm in Pixel.
2. Visuelle Effekte animieren, mit denen die Inhalte von einem Zustand zum anderen geändert werden können.
3. Je nach Eingabe wird gescrollt.
4. Eingaben effizient an die richtigen Orte weiterleiten, damit Entwicklerskripts und andere Subsysteme antworten können

Der Inhalt, der gerendert werden soll, besteht aus einer Baumstruktur von Frames für jeden Browsertab sowie der Browseroberfläche. und einen Strom von Roheingabeereignissen von Touchscreens, Mäusen, Tastaturen und anderen Hardwaregeräten.

Jeder Frame enthält Folgendes:

• DOM-Status
• CSS
• Canvases
• Externe Ressourcen wie Bilder, Videos, Schriftarten und SVG

Ein Frame ist ein HTML-Dokument und seine URL. Eine Webseite, die auf einem Browsertab geladen wird, enthält einen Frame auf oberster Ebene, untergeordnete Frames für jeden iFrame, der im Dokument auf oberster Ebene enthalten ist, und ihre rekursiven iFrame-Nachfolgerelemente.

Ein visueller Effekt ist ein grafischer Vorgang, der auf eine Bitmap angewendet wird, z. B. Scrollen, Transformieren, Abschneiden, Filtern, Deckkraft oder Überblenden.

Architekturkomponenten

Beim RenderingNG sind diese Aufgaben logisch auf mehrere Phasen und Codekomponenten aufgeteilt. Die Komponenten befinden sich in verschiedenen CPU-Prozessen, ‐Threads und Unterkomponenten innerhalb dieser Threads. Beides spielt eine wichtige Rolle dabei, Zuverlässigkeit, skalierbare Leistung und Erweiterbarkeit für alle Webinhalte zu erreichen.

Struktur der Rendering-Pipeline

Pfeile kennzeichnen die Ein- und Ausgaben der einzelnen Phasen. Phasen sind farblich gekennzeichnet, um zu zeigen, welcher Thread oder Prozess sie ausführen. In einigen Fällen können Phasen je nach Situation an mehreren Stellen ausgeführt werden. Daher haben manche Phasen auch zwei Farben. Grüne Phasen sind der Hauptthread des Renderingprozesses; Gelb sind Kompositoren des Renderingprozesses. Orangefarbene Phasen sind der Visualisierungsprozess.

Das Rendering erfolgt in einer Pipeline mit einer Reihe von Phasen und Artefakten, die dabei erstellt werden. Jede Phase steht für Code, der eine genau definierte Aufgabe innerhalb des Renderings ausführt. Die Artefakte sind Datenstrukturen, die Ein- oder Ausgaben der Phasen sind.

Die Phasen sind:

1. Animieren:Ändern Sie berechnete Stile und passen Sie Eigenschaftsstrukturen im Laufe der Zeit basierend auf deklarativen Zeitachsen an.
2. Stil:CSS wird auf das DOM angewendet und berechnete Stile erstellt.
3. Layout:Bestimmen Sie die Größe und Position der DOM-Elemente auf dem Bildschirm und erstellen Sie die unveränderliche Fragmentstruktur.
4. Pre-paint:Berechnen Sie Attributstrukturen und entwerten Sie vorhandene Anzeigelisten und GPU-Texturkacheln entsprechend.
5. Scrollen:Aktualisieren Sie den Scroll-Offset von Dokumenten und scrollbaren DOM-Elementen, indem Sie Eigenschaftenstrukturen ändern.
6. Paint:Eine Anzeigeliste berechnen, in der beschrieben wird, wie GPU-Texturkacheln aus dem DOM gerastert werden.
7. Commit:Kopiert Attributstrukturen und die Anzeigeliste in den zusammengesetzten Thread.
8. Ebenen erstellen:Hiermit wird die Anzeigeliste zur unabhängigen Rasterung und Animation in eine Liste mit zusammengesetzten Ebenen unterteilt.
9. Raster-, Decodierungs- und Paint-Worklets: Wandeln Sie Displaylisten, codierte Bilder bzw. Paint-Worklet-Code in GPU-Texturkacheln um.
10. Aktivieren:Erstellen Sie einen Compositor-Frame, der festlegt, wie GPU-Kacheln gezeichnet und positioniert werden, zusammen mit visuellen Effekten.
11. Aggregieren:Kombiniert zusammengesetzte Frames aus allen sichtbaren zusammengesetzten Frames zu einem einzigen globalen zusammengesetzten Frame.
12. Draw:Führt den aggregierten Compositor-Frame auf der GPU aus, um Pixel auf dem Bildschirm zu erstellen.

Phasen der Rendering-Pipeline können übersprungen werden, wenn sie nicht benötigt werden. Bei Animationen mit visuellen Effekten und beim Scrollen können beispielsweise Layout, Voranstrich und Paint übersprungen werden. Aus diesem Grund sind Animationen und Scrollen mit gelben und grünen Punkten im Diagramm gekennzeichnet. Wenn Layout, Prepaint und Paint für visuelle Effekte übersprungen werden können, können sie vollständig auf dem Compositor-Thread ausgeführt und den Hauptthread übersprungen werden.

Das UI-Rendering des Browsers wird hier nicht direkt dargestellt. Es ist jedoch eine vereinfachte Version derselben Pipeline, die tatsächlich einen Großteil des Codes verwendet. Videos (auch nicht direkt dargestellt) werden im Allgemeinen mit unabhängigem Code gerendert, der Frames in GPU-Texturkacheln decodiert, die dann in Compositor-Frames und im Zeichenschritt eingesteckt werden.

Prozess- und Thread-Struktur

Hinweis: In der Chromium-Architektur gibt es mehr CPU-Prozesse und -Threads als in diesem Dokument dargestellt. Diese Diagramme konzentrieren sich nur auf das, was für das Rendering entscheidend ist.

CPU-Prozesse

Durch die Verwendung mehrerer CPU-Prozesse wird eine Leistungs- und Sicherheitsisolierung zwischen Standorten und dem Browserstatus sowie die Stabilität und Sicherheitsisolierung von GPU-Hardware erreicht.

• Beim Renderingprozess werden Eingaben für eine einzelne Website- und Tab-Kombination gerendert, animiert, gescrollt und weitergeleitet. Es gibt mehrere Renderingprozesse.
• Der Browserprozess rendert, animiert und leitet die Eingaben für die Browser-Benutzeroberfläche (einschließlich der Adressleiste, Tabtitel und Symbole) weiter und alle verbleibenden Eingaben werden an den entsprechenden Renderingprozess weitergeleitet. Es gibt einen Browser-Prozess.
• Der Viz-Prozess aggregiert die Zusammensetzung aus mehreren Renderingprozessen und dem Browserprozess. Sie rastert und zeichnet mit GPU. Es gibt einen Visualisierungsprozess.

Unterschiedliche Websites haben immer unterschiedliche Renderingprozesse.

Hinweis :In Wirklichkeit gilt das immer auf Computern und nur wenn möglich auf Mobilgeräten. Dieser Vorbehalt gilt für alle Fälle.

Für mehrere Browsertabs oder -fenster derselben Website werden normalerweise verschiedene Renderingprozesse ausgeführt, es sei denn, die Tabs haben einen Bezug zueinander. Beispielsweise wird der andere geöffnet. Bei hoher Speicherauslastung in der Desktopversion kann Chromium mehrere Tabs derselben Website in denselben Renderingprozess verschieben, auch wenn sie keinen Bezug zueinander haben.

Auf einem einzigen Browsertab befinden sich die Frames von verschiedenen Websites immer in unterschiedlichen Renderingprozessen. Frames derselben Website durchlaufen jedoch immer denselben Renderingprozess. Aus Sicht des Renderings besteht der wichtige Vorteil mehrerer Renderingprozesse darin, dass websiteübergreifende iFrames und Tabs eine Leistungsisolierung voneinander erreichen. Darüber hinaus können Ursprünge eine noch mehr Isolation aktivieren.

Es gibt genau einen Visualisierungsprozess für den gesamten Chromium-Code, da normalerweise nur eine GPU und ein Bildschirm zum Zeichnen vorhanden sind.

Die Unterteilung von Viz in einen eigenen Prozess sorgt für Stabilität bei Fehlern in GPU-Treibern oder -Hardware. Sie eignet sich auch zur Sicherheitsisolation, die für GPU-APIs wie Vulkan und Sicherheit im Allgemeinen wichtig ist.

Da der Browser viele Tabs und Fenster haben kann, von denen alle Browser-UI-Pixel zeichnen können, fragen Sie sich vielleicht: Warum gibt es genau einen Browserprozess? Der Grund dafür ist, dass jeweils nur einer von ihnen im Fokus ist. Tatsächlich werden nicht sichtbare Browser-Tabs größtenteils deaktiviert und der gesamte GPU-Arbeitsspeicher gelöscht. Komplexe Renderingfunktionen für die Browser-UI werden jedoch zunehmend in Renderingprozessen implementiert (sogenannte WebUI). Dies geschieht nicht aus Gründen der Leistungsisolierung, sondern um die Nutzerfreundlichkeit der Web-Rendering-Engine von Chromium zu nutzen.

Auf älteren Android-Geräten werden der Rendering- und Browserprozess geteilt, wenn sie in einem WebView verwendet werden. Dies gilt nicht für Chromium unter Android im Allgemeinen, nur für WebView. Bei WebView wird der Browserprozess auch mit der Einbettungs-App geteilt und WebView hat nur einen Renderingprozess.

Manchmal gibt es auch einen Dienstprogrammprozess zum Decodieren geschützter Videoinhalte. Dieser Prozess ist in den vorherigen Diagrammen nicht dargestellt.

Unterhaltungen

Threads tragen trotz langsamer Aufgaben, Pipelineparallelisierung und mehrfacher Zwischenspeicherung zu Leistungsisolation und Reaktionsfähigkeit bei.

• Im Hauptthread werden Skripts, die Rendering-Ereignisschleife, der Dokumentlebenszyklus, Treffertests, die Weiterleitung von Skriptereignissen und das Parsen von HTML-, CSS- und anderen Datenformaten ausgeführt.
  • Hilfsprogramme für den Hauptthread führen Aufgaben wie das Erstellen von Bild-Bitmaps und Blobs aus, die eine Codierung oder Decodierung erfordern.
  • Web Worker führen ein Script und eine Rendering-Ereignisschleife für OffscreenCanvas aus.
• Der Compositor-Thread verarbeitet Eingabeereignisse, führt Scrollen und Animationen von Webinhalten durch, berechnet die optimale Schichtierung von Webinhalten und koordiniert Bilddecodierungen, Paint-Worklets und Rasteraufgaben.
  • Compositor-Thread-Hilfsprogramme koordinieren Viz-Rasteraufgaben und führen Bilddecodierungsaufgaben, Paint-Worklets und Fallback-Raster aus.
• Medien-, Demuxer- oder Audioausgabe-Threads decodieren, verarbeiten und synchronisieren Video- und Audiostreams. Denken Sie daran, dass das Video parallel zur Haupt-Rendering-Pipeline ausgeführt wird.

Die Trennung des Haupt- und des Compositor-Threads ist für die Leistungsisolierung von Animationen und Scrollen vom Hauptthread von entscheidender Bedeutung.

Pro Renderingprozess gibt es nur einen Hauptthread, auch wenn mehrere Tabs oder Frames von derselben Website im selben Prozess enden. Es besteht jedoch eine Leistungsisolation bei der Arbeit in verschiedenen Browser-APIs. Zum Beispiel wird die Generierung von Bild-Bitmaps und Blobs in der Canvas API in einem Helper-Thread des Hauptthreads ausgeführt.

Ebenso gibt es nur einen Compositor-Thread pro Renderingprozess. Im Allgemeinen ist es kein Problem, dass es nur einen gibt, da alle sehr teuren Vorgänge auf den Compositor-Thread entweder an Compositor-Worker-Threads oder an den Viz-Prozess delegiert werden und diese Arbeit parallel mit Eingaberouting, Scrollen oder Animation erfolgen kann. Compositor-Worker-Threads koordinieren Aufgaben, die im Viz-Prozess ausgeführt werden. Die GPU-Beschleunigung überall kann jedoch aus Gründen, die außerhalb der Kontrolle von Chromium liegen, ausfallen, z. B. Treiberfehler. In diesen Fällen führt der Worker-Thread die Arbeit im Fallback-Modus auf der CPU aus.

Die Anzahl der zusammengesetzten Worker-Threads hängt von den Funktionen des Geräts ab. Beispielsweise verwenden Computer in der Regel mehr Threads, da sie mehr CPU-Kerne haben und weniger akku als Mobilgeräte haben. Dies ist ein Beispiel für das Hoch- und Herunterskalieren.

Die Threading-Architektur des Renderingprozesses ist eine Anwendung von drei verschiedenen Optimierungsmustern:

• Hilfsthreads: Senden von Unteraufgaben mit langer Ausführungszeit an zusätzliche Threads, damit der übergeordnete Thread auf andere, gleichzeitige Anfragen reagiert. Gute Beispiele für diese Technik sind die Helper- und Compositor-Hilfsthreads.
• Mehrfache Zwischenspeichern: Beim Rendern neuer Inhalte werden zuvor gerenderte Inhalte angezeigt, um die Rendering-Latenz auszublenden. Der Compositor-Thread verwendet diese Technik.
• Pipelineparallelisierung:Führt die Rendering-Pipeline an mehreren Stellen gleichzeitig aus. So können Scrollen und Animationen schnell sein. Auch wenn ein Update für das Hauptthread-Rendering stattfindet, können Scrollen und Animationen parallel ausgeführt werden.

Browserprozess

• Der Rendering- und Compositing-Thread reagiert auf Eingaben in der Browser-UI und leitet andere Eingaben an den richtigen Renderingprozess weiter. Er erstellt das Layout und die Darstellung der Browser-UI.
• Die Hilfsprogramme für Rendering- und Compositing-Threads führen Bilddecodierungsaufgaben und Fallback-Raster- oder Decodierungsaufgaben aus.

Der Rendering- und Zusammensetzungs-Thread des Browsers ähnelt dem Code und der Funktionalität eines Rendering-Prozesses, mit der Ausnahme, dass der Hauptthread und der zusammengesetzte Thread zu einem zusammengeführt werden. In diesem Fall ist nur ein Thread erforderlich, da keine Leistungsisolierung von Aufgaben mit langen Hauptthreads besteht, da diese grundsätzlich nicht vorhanden sind.

Visualisierungsprozess

• Die Raster des GPU-Hauptthreads zeigen Listen und Videoframes in GPU-Texturkacheln an und zeichnen Compositor-Frames auf den Bildschirm.
• Der Compositor-Thread aggregiert und optimiert die Zusammensetzung aus jedem Renderingprozess sowie dem Browserprozess in einem einzelnen Compositor-Frame für die Darstellung auf dem Bildschirm.

Das Rastern und das Zeichnen erfolgen im Allgemeinen im selben Thread, da beide GPU-Ressourcen benötigen und es schwierig ist, die GPU zuverlässig Multithreads zu nutzen. Ein einfacherer Multithread-Zugriff auf die GPU ist eine Motivation für die Entwicklung des neuen Vulkan-Standards. Bei Android WebView gibt es einen separaten Renderingthread auf Betriebssystemebene zum Zeichnen, da WebViews in eine native App eingebettet sind. Für andere Plattformen wird es in Zukunft wahrscheinlich einen solchen Thread geben.

Der Display-Compositor befindet sich in einem anderen Thread, da er immer responsiv sein muss und nicht aufgrund einer möglichen Verlangsamung im GPU-Hauptthread blockiert werden darf. Eine Ursache für die Verlangsamung im GPU-Hauptthread sind Aufrufe von Nicht-Chromium-Code, z. B. anbieterspezifische GPU-Treiber, die auf unvorhersehbare Weise langsam sein können.

Komponentenstruktur

Innerhalb jedes Haupt- oder zusammengesetzten Threads gibt es logische Softwarekomponenten, die auf strukturierte Weise miteinander interagieren.

Renderingprozess – Hauptthreadkomponenten

Im Blink-Renderer:

• Das lokale Framestrukturfragment stellt die Baumstruktur lokaler Frames und das DOM innerhalb der Frames dar.
• Die Komponente DOM und Canvas APIs enthält Implementierungen dieser APIs.
• Der Runner für den Dokumentlebenszyklus führt die Rendering-Pipelineschritte bis zum Commit-Schritt aus.
• Die Komponente Treffertests und Weiterleitung von Eingabeereignissen führt Treffertests aus, um herauszufinden, auf welches DOM-Element ein Ereignis abzielt, und führt die Algorithmen und das Standardverhalten der Eingabeereignisse aus.

Der Planer und Runner für die Rendering-Ereignisschleife bestimmt, was wann in der Ereignisschleife ausgeführt wird. Das Rendering wird so geplant, dass es in einem Rhythmus erfolgt, der mit dem Gerätedisplay übereinstimmt.

Lokale Frame Tree-Fragmente sind etwas kompliziert. Denken Sie daran, dass eine Frame-Struktur rekursiv die Hauptseite und ihre untergeordneten iFrames ist. Ein Frame ist für einen Renderingprozess lokal, wenn er dabei gerendert wird. Andernfalls ist er extern.

Sie können sich die Frames entsprechend ihrem Renderingprozess kolorieren. Im vorherigen Bild sind die grünen Kreise alle Frames in einem Renderingprozess. Die orangefarbenen Kreise befinden sich in einer Sekunde und der blaue in einem dritten.

Ein lokales Framebaumfragment ist eine verbundene Komponente derselben Farbe in einer Framestruktur. Im Bild sind vier lokale Rahmenbäume zu sehen: zwei für Standort A, eine für Standort B und eine für Standort C. Jede lokale Frame-Struktur erhält eine eigene Blink-Renderer-Komponente. Der Blink-Renderer einer lokalen Framestruktur kann sich im selben Renderingprozess befinden wie andere lokale Framestrukturen. Sie wird wie oben beschrieben durch die Auswahl der Renderingprozesse bestimmt.

Aufbau des Compositor-Threads des Renderingprozesses

Die zusammengesetzten Komponenten des Renderingprozesses umfassen:

• Data-Handler, der eine Liste mit zusammengesetzten Ebenen verwaltet, Listen und Property-Strukturen anzeigt
• Ein Lebenszyklus-Runner, der die Schritte zum Animieren, Scrollen, Erstellen, Rastern, Decodieren und Aktivieren der Rendering-Pipeline ausführt. Denken Sie daran, dass Animieren und Scrollen sowohl im Hauptthread als auch im Compositor vorkommen können.
• Ein Eingabe- und Treffertest-Handler führt eine Eingabeverarbeitung und Treffertests mit der Auflösung der zusammengesetzten Ebenen durch, um festzustellen, ob Scrollbewegungen auf dem zusammengesetzten Thread ausgeführt werden können und auf welchen Renderingprozess Treffertests ausgerichtet werden sollen.

Beispielarchitektur in der Praxis

In diesem Beispiel gibt es drei Tabs:

Tab 1: foo.com

<html>
  <iframe id=one src="foo.com/other-url"></iframe>
  <iframe  id=two src="bar.com"></iframe>
</html>

Tab 2: bar.com

<html>
 …
</html>

Tab 3: baz.com html <html> … </html>

Der Prozess, der Thread und die Komponentenstruktur für diese Registerkarten sehen so aus:

Sehen wir uns ein Beispiel für jede der vier Hauptaufgaben des Renderings an. Zur Erinnerung:

1. Rendern Sie Inhalte auf dem Bildschirm in Pixel.
2. Animieren Sie visuelle Effekte auf die Inhalte von einem Zustand zum anderen.
3. Je nach Eingabe wird gescrollt.
4. Leiten Sie Eingaben effizient an die richtigen Orte weiter, damit Entwicklerskripts und andere Subsysteme antworten können.

So rendern Sie das geänderte DOM für Tab 1:

1. Ein Entwicklerskript ändert das DOM im Renderingprozess für foo.com.
2. Der Blink-Renderer teilt dem Compositor mit, dass ein Rendering erforderlich ist.
3. Der Compositor teilt Viz mit, dass ein Rendering erfolgen muss.
4. Viz signalisiert dem Compositor den Beginn des Renderings.
5. Der Compositor leitet das Startsignal an den Blink-Renderer weiter.
6. Der Hauptthread-Ereignisschleifen-Runner führt den Dokumentlebenszyklus aus.
7. Der Hauptthread sendet das Ergebnis an den zusammengesetzten Thread.
8. Der Ausführungsschleife der Ereignisschleife des zusammengesetzten Ereignisses führt den Compositing-Lebenszyklus aus.
9. Alle Rasteraufgaben werden für die Rasterung an Viz gesendet. Häufig gibt es mehrere dieser Aufgaben.
10. Viz-Rasterinhalte auf der GPU.
11. Viz bestätigt den Abschluss der Rasteraufgabe. Hinweis: Chromium wartet häufig nicht, bis das Raster abgeschlossen ist. Stattdessen verwendet Chromium ein sogenanntes Synchronisierungstoken, das von Rasteraufgaben aufgelöst werden muss, bevor Schritt 15 ausgeführt wird.
12. Ein zusammengesetzter Frame wird an Viz gesendet.
13. Viz aggregiert die Compositor-Frames für den foo.com-Renderingprozess, den bar.com-iFrame-Renderingprozess und die Browser-UI.
14. Visualisierung plant ein Remis.
15. Viz zeichnet den aggregierten Compositor-Frame auf den Bildschirm.

So animieren Sie einen CSS-Transformationsübergang auf Tab 2:

1. Der Compositor-Thread für den Renderingprozess von bar.com markiert eine Animation in seiner Compositor-Ereignisschleife, indem er die vorhandenen Attributstrukturen verändert. Anschließend wird der Compositor-Lebenszyklus noch einmal ausgeführt. (Es können Aufgaben Raster- und Decodierungsaufgaben ausgeführt werden, die hier nicht dargestellt sind.)
2. Ein zusammengesetzter Frame wird an Viz gesendet.
3. Viz aggregiert die Compositor-Frames für den foo.com-Renderingprozess, den bar.com-Renderingprozess und die Browser-Benutzeroberfläche.
4. Visualisierung plant ein Remis.
5. Viz zeichnet den aggregierten Compositor-Frame auf den Bildschirm.

So scrollen Sie auf Tab 3 durch die Webseite:

1. Im Browserprozess wird eine Folge von input-Ereignissen (Maus, Berührung oder Tastatur) erfasst.
2. Jedes Ereignis wird an den zusammengesetzten Thread des Renderingprozesses von baz.com weitergeleitet.
3. Der Compositor bestimmt, ob der Hauptthread Informationen zu dem Ereignis benötigt.
4. Das Ereignis wird bei Bedarf an den Hauptthread gesendet.
5. Der Hauptthread löst input-Event-Listener (pointerdown, touchstar, pointermove, touchmove oder wheel) aus, um zu sehen, ob Listener preventDefault für das Ereignis aufrufen.
6. Der Hauptthread gibt zurück, ob preventDefault an den Compositor aufgerufen wurde.
7. Andernfalls wird das Eingabeereignis an den Browserprozess zurückgesendet.
8. Der Browserprozess konvertiert sie in eine Scroll-Geste, indem sie mit anderen aktuellen Ereignissen kombiniert wird.
9. Die Scroll-Geste wird noch einmal an den Compositor-Thread von baz.com gesendet,
10. Dort wird das Scrollen angewendet und der Compositor-Thread für den bar.com-Renderingprozess markiert eine Animation in seiner zusammengesetzten Ereignisschleife. Dadurch wird dann der Scroll-Offset in den Eigenschaftenstrukturen mutiert und der Compositor-Lebenszyklus erneut ausgeführt. Außerdem wird damit der Hauptthread angewiesen, ein scroll-Ereignis auszulösen (hier nicht dargestellt).
11. Ein zusammengesetzter Frame wird an Viz gesendet.
12. Viz aggregiert die Compositor-Frames für den foo.com-Renderingprozess, den bar.com-Renderingprozess und die Browser-UI.
13. Visualisierung plant ein Remis.
14. Viz zeichnet den aggregierten Compositor-Frame auf den Bildschirm.

Hinweis :Jedes Eingabeereignis nach dem ersten kann die Schritte 3 und 4 überspringen, da das Scrollen bereits begonnen hat. Skripts können dies über das scroll-Ereignis beobachten und nicht unterbrechen.

So leiten Sie ein click-Ereignis über einen Hyperlink in iFrame 2 auf Tab 1 weiter:

1. Ein input-Ereignis (Maus, Berührung oder Tastatur) wird im Browserprozess eingefügt. Es führt einen ungefähren Treffertest durch, um festzustellen, ob der iFrame-Renderingprozess von bar.com den Klick empfangen sollte, und sendet ihn dorthin.
2. Der Compositor-Thread für bar.com leitet das click-Ereignis an den Hauptthread für bar.com weiter und plant eine Rendering-Ereignisschleife für die Verarbeitung.
3. Der Eingabeereignisprozessor für den Hauptthread von bar.com testet, auf welches DOM-Element im iFrame geklickt wurde, und löst ein click-Ereignis aus, damit Skripts beobachtet werden. Wenn preventDefault nicht angezeigt wird, wird der Hyperlink aufgerufen.
4. Beim Laden der Landingpage des Hyperlinks wird der neue Status mit den Schritten gerendert, die dem vorherigen Beispiel „Geändertes DOM rendern“ ähneln. (Die nachfolgenden Änderungen sind hier nicht enthalten.)

Tipp

Es kann viel Zeit dauern, sich zu merken und zu verinnerlichen, wie das Rendering funktioniert.

Die wichtigste Erkenntnis ist, dass die Rendering-Pipeline durch sorgfältige Modularisierung und Liebe zum Detail in mehrere eigenständige Komponenten aufgeteilt wurde. Diese Komponenten wurden dann auf parallele Prozesse und Threads aufgeteilt, um die skalierbare Leistung und die Erweiterbarkeit zu maximieren.

Jede Komponente spielt eine entscheidende Rolle bei der Umsetzung der Leistung und Funktionen moderner Webanwendungen.

Lesen Sie weiter zu den Schlüsseldatenstrukturen, die für RenderingNG genauso wichtig sind wie Codekomponenten.

---

Illustrationen von Una Kravets