ארכיטקטורת RenderingNG

Chris Harrelson
Chris Harrelson
X GitHub

כאן תוכלו ללמוד איך הרכיבים של RenderingNG מוגדרים, ואיך צינור עיבוד הנתונים של הרינדור עובר דרכם.

החל מהרמה הגבוהה ביותר, משימות הרינדור הן:

  1. רינדור התוכן לפיקסלים במסך.
  2. הוספת אנימציות של אפקטים חזותיים לתוכן ממצב אחד לאחר.
  3. גוללים בתגובה לקלט.
  4. ניתוב קלט ביעילות למקומות הנכונים כדי שהסקריפטים של המפתחים ומערכות משנה אחרות יוכלו להגיב.

התוכן לעיבוד הוא עץ של מסגרות לכל כרטיסייה בדפדפן, וגם ממשק הדפדפן. וגם זרם של אירועי קלט גולמיים ממסכי מגע, עכברים, מקלדות ומכשירי חומרה אחרים.

כל מסגרת כוללת:

  • מצב DOM
  • CSS
  • קנבסים
  • משאבים חיצוניים כמו תמונות, וידאו, גופנים ו-SVG

מסגרת היא מסמך HTML, וגם כתובת ה-URL שלו. לדף אינטרנט שנטען בכרטיסייה בדפדפן יש מסגרת ברמה העליונה, פריימים צאצאים לכל iframe במסמך ברמה העליונה, וצאצאים רקורסיביים של iframe.

אפקט חזותי הוא פעולה גרפית שמופעלת על מפת סיביות (bitmap), כמו גלילה, טרנספורמציה, חיתוך, פילטר, אטימוּת או מיזוג.

רכיבי ארכיטקטורה

ב-RenderingNG המשימות האלה מחולקות באופן לוגי בין כמה שלבים ומרכיבי קוד. הרכיבים מגיעים בסופו של דבר לתהליכים, לשרשורים ולרכיבי משנה שונים של המעבד (CPU) בתוך השרשורים האלה. לכל סוג תוכן יש תפקיד חשוב באמינות, בביצועים שניתנים להרחבה ובהרחבה לכל התוכן באינטרנט.

מבנה צינור עיבוד הנתונים לעיבוד

תרשים של צינור עיבוד הנתונים.
החיצים מציינים את הקלט והפלט של כל שלב. השלבים מסומנים בצבע כדי להדגים איזה שרשור או תהליך הם מבצעים. בחלק מהמקרים, השלבים יכולים להופיע בכמה מקומות, בהתאם לנסיבות, ולכן לחלק מהם יש שני צבעים. שלבים ירוקים מעבדים את ה-thread הראשי; צהוב הם מרכיבי תהליכים; שלבים כתומים הם תהליך ה-Viz.

העיבוד מתבצע בצינור עיבוד נתונים שכולל מספר שלבים וארטיפקטים שנוצרים לאורך הדרך. כל שלב מייצג קוד שמבצע משימה אחת מוגדרת היטב במהלך העיבוד. פריטי המידע שנוצרו בתהליך הפיתוח (Artifact) הם מבני נתונים שמשמשים כקלט או כפלט של השלבים.

השלבים הם:

  1. אנימציה: שינוי הסגנונות המחושבים ושינוי של עצי המאפיינים לאורך זמן על סמך צירי זמן הצהרתיים.
  2. סגנון: החלת CSS על ה-DOM ויצירת סגנונות מחושבים.
  3. פריסה: קביעת הגודל והמיקום של רכיבי DOM במסך, ויצירת עץ המקטעים שלא ניתן לשינוי.
  4. Pre-color: חישוב עצי נכסים וביטול התוקף של כל רשימות התצוגה ומשבצות המרקם הקיימות של ה-GPU, לפי הצורך.
  5. גלילה: מעדכנים את היסט הגלילה של מסמכים ורכיבי DOM שניתנים לגלילה, על ידי שינוי של עצי מאפיינים.
  6. צבע: חישוב רשימת תצוגה שמתארת איך לרנדר משבצות של טקסטורה של GPU מה-DOM.
  7. מחויבות: מעתיקים את עצי המאפיינים ואת רשימת התצוגה לשרשור של המחבר.
  8. יצירת שכבות: מפצלים את רשימת התצוגה לרשימת שכבות מורכבת כדי ליצור רשת פשוטה ואנימציה עצמאית.
  9. ערכי worklet של רסטר, פענוח וצבע: הופכים רשימות תצוגה, תמונות מקודדות וקוד worklet של צבע, בהתאמה, למשבצות של טקסטורה ב-GPU.
  10. הפעלה: יוצרים מסגרת קומפוזבילי שמייצגת איך לצייר משבצות GPU ולמקם אותן על המסך, ביחד עם אפקטים חזותיים.
  11. צבירה: שילוב פריימים של קומפוזבילי מכל הפריימים הגלויים של קומפוזביליים למסגרת אחת וגלובלית של קומפוזבילי.
  12. שרטוט: הפעלת מסגרת הקומפוזיציה המצטברת ב-GPU כדי ליצור פיקסלים במסך.

אפשר לדלג על השלבים בצינור עיבוד הנתונים של העיבוד אם אין בהם צורך. לדוגמה: אנימציות של אפקטים חזותיים וגלילה יכולות לדלג על פריסה, ציור מראש וציור. לכן אנימציה וגלילה מסומנות בנקודות צהובות וירוקות בתרשים. אם אפשר לדלג על פריסה, צבע מראש וצבע כדי להשתמש באפקטים חזותיים, אפשר להריץ אותם רק על השרשור הראשי ולדלג על השרשור הראשי.

הרינדור של ממשק המשתמש של הדפדפן לא מתואר כאן, אבל אפשר להתייחס אליו כאל גרסה פשוטה של צינור עיבוד הנתונים הזה (ולמעשה, ההטמעה של חלק גדול מהקוד משותפת). וידאו (גם לא מתואר באופן ישיר) בדרך כלל מעבד באמצעות קוד עצמאי שמפענח פריימים למשבצות טקסטורה של GPU, שמחוברות לאחר מכן למסגרות של קומפוזבילי ולשלב השרטוט.

מבנה התהליך ומבנה השרשורים

תהליכי מעבד (CPU)

השימוש במספר תהליכי מעבד (CPU) משפר את הביצועים ואת בידוד האבטחה בין אתרים וממצב הדפדפן, ומאפשר בידוד יציב ואבטחה מחומרת GPU.

תרשים של החלקים השונים של תהליכי המעבד

  • בתהליך העיבוד מתבצע רינדור, אנימציה, גלילות ומסלולים לקלט של שילוב יחיד של אתר וכרטיסיות. יש כמה תהליכי עיבוד.
  • תהליך הדפדפן מעבד, מונפש ומנתב קלט לממשק המשתמש של הדפדפן (כולל סרגל הכתובות, כותרות הכרטיסיות והסמלים), ומנתב את כל הקלט שנותר לתהליך העיבוד המתאים. יש תהליך דפדפן אחד.
  • תהליך Viz צובר את המורכבות מכמה תהליכי רינדור, וגם מתהליך הדפדפן. הוא יוצר רסטר ושורטט באמצעות ה-GPU. יש תהליך אחד Viz.

אתרים שונים תמיד מסתיימים בתהליכי עיבוד שונים.

בדרך כלל, כרטיסיות או חלונות מרובים באותו אתר עוברים תהליכי רינדור שונים, אלא אם הכרטיסיות קשורות, למשל פתיחה אחת של השנייה. כשיש עומס חזק על הזיכרון במחשב, Chromium עשוי להעביר כמה כרטיסיות מאותו אתר לאותו תהליך רינדור, גם אם אין להן קשר כזה.

בכרטיסייה אחת בדפדפן, פריימים מאתרים שונים תמיד נמצאים בתהליכי עיבוד שונים זה מזה, אבל פריימים מאותו אתר תמיד נמצאים באותו תהליך עיבוד. מבחינת הרינדור, היתרון החשוב של תהליכי רינדור מרובים הוא שמסגרות iframe וכרטיסיות חוצות-אתרים מאפשרות בידוד ביצועים אחד מהשני. בנוסף, מקורות יכולים להביע הסכמה לבידוד חריג יותר.

ב-Chromium יש בדיוק תהליך אחד של Viz, כי בדרך כלל יש רק GPU אחד ומסך אחד שאפשר למשוך אליו.

הפרדה של Viz לתהליך משלה עוזרת לשמור על יציבות מול באגים במנהלי התקנים או בחומרה של GPU. הוא טוב גם לבידוד אבטחה, כי הוא חשוב לממשקי API של GPU כמו Vulkan ולאבטחה באופן כללי.

מכיוון שבדפדפן יכולים להיות הרבה כרטיסיות וחלונות, ולכולם יש פיקסלים בממשק המשתמש של הדפדפן. לכן, אולי תשאלו את עצמכם: למה יש בדיוק תהליך אחד בדפדפן? הסיבה לכך היא שרק אחת מהן ממוקדת בכל פעם. למעשה, כרטיסיות דפדפן שאינן גלויות מושבתות בדרך כלל ומשחררות את כל הזיכרון שלהן ב-GPU. עם זאת, יותר ויותר תכונות מורכבות של רינדור בממשק המשתמש של הדפדפן מיושמות בתהליכי רינדור (שנקראים WebUI). הכלל הזה לא נועד לבודד את הביצועים, אלא כדי לנצל את קלות השימוש במנוע העיבוד של Chromium באינטרנט.

במכשירי Android ישנים יותר, העיבוד ותהליך הדפדפן משותפים כשמשתמשים ב-WebView (לא חל על Chromium ב-Android באופן כללי, אלא רק על WebView). ב-WebView, תהליך הדפדפן משותף גם עם אפליקציית ההטמעה, וב-WebView יש תהליך רינדור אחד בלבד.

לפעמים יש גם תהליך עזר לפענוח תוכן וידאו מוגן. התהליך הזה לא מתואר בתרשימים הקודמים.

שרשורים

שרשורים עוזרים לבודד את הביצועים ולהגביר את הרספונסיביות למרות משימות איטיות, מקבילה של צינור עיבוד נתונים ומאגר נתונים זמני מרובים.

תרשים של תהליך העיבוד.

  • ה-thread הראשי מפעיל סקריפטים, לולאת אירוע הרינדור, מחזור החיים של המסמך, בדיקת היטים, שליחת אירועי סקריפט וניתוח של HTML, CSS ופורמטים אחרים של נתונים.
    • עוזרים עיקריים לשרשורים מבצעים משימות כמו יצירת מפות סיביות של תמונות ו-blobs שמחייבים קידוד או פענוח.
    • Web Workers מריצים סקריפט ולולאת אירוע רינדור עבור OffscreenCanvas.
  • השרשור בקומפוזיטור מעבד אירועי קלט, מבצע גלילה ואנימציות של תוכן אינטרנט, מחשב שכבות אופטימליות של תוכן האינטרנט ומתאם בין פענוח קוד של תמונות, worklets של ציור, ומשימות של רסטר.
    • עוזרים לשרשורים בקומפוזיטור מתאמים משימות של Viz Raster, וביצוע משימות של פענוח קוד של תמונות, worklets של ציור, ו-fallback raster.
  • שרשורים של מדיה, demuxer או פלט אודיו מפענחים, מעבדים ומסנכרנים שידורי וידאו ואודיו. (חשוב לזכור שהסרטון מופעל במקביל לצינור העיבוד הראשי).

חשוב מאוד להפריד בין ה-thread הראשי לבין ה-threads של המרכיב כדי לבודד את הביצועים של האנימציה והגלילה מהתהליך של ה-thread הראשי.

בכל תהליך רינדור יש רק שרשור ראשי אחד, למרות שכמה כרטיסיות או פריימים מאותו אתר עשויות להגיע לאותו תהליך. עם זאת, יש הפרדה בין הביצועים לעבודה שמבוצעת בממשקי API שונים בדפדפנים. לדוגמה, יצירה של מפות סיביות ו-blobs של תמונות ב-Canvas API פועלות בשרשור ראשי של thread.

בדומה לכך, יש רק שרשור קומפוזבילי אחד לכל תהליך רינדור. בדרך כלל זו לא בעיה שיש רק אחת, כי כל הפעולות היקרות ביותר בשרשורים של הקומפוזבילי מוקצות לשרשורים של עובדים קומפוזביליים או לתהליך Viz, ואפשר לבצע את העבודה הזו במקביל עם ניתוב קלט, גלילה או אנימציה. שרשורים של עובדים קומפוזבילי קואורדינטות שרצים בתהליך Viz, אבל האצת GPU בכל מקום עלולה להיכשל מסיבות שלא בשליטת Chromium, כמו באגים במנהל התקן. במצבים כאלה, ה-thread של העובד יבצע את הפעולה במצב חלופי במעבד.

מספר ה-threads של קומפוזיציה תלוי ביכולות של המכשיר. לדוגמה, מחשבים בדרך כלל משתמשים ביותר תהליכונים במקביל, כי יש בהם יותר ליבות של מעבד (CPU) ופחות ליבות שלהם מוגבלים על ידי צריכת הסוללה מאשר במכשירים ניידים. זוהי דוגמה להגדלה והקטנה של נפח האחסון.

ארכיטקטורת השרשור של תהליכי העיבוד היא יישום של שלושה דפוסי אופטימיזציה שונים:

  • שרשורי עזרה: שליחת תתי-משימות ממושכות לשרשורים נוספים כדי לאפשר לשרשור ההורה להגיב לבקשות אחרות שמתבצעות בו-זמנית. דוגמאות טובות לשיטה הזו היא כלי ה-thread הראשי ושרשורי העזר מסוג compositor.
  • אחסון במאגר נתונים זמני: הצגת תוכן שעבר רינדור בעבר בזמן רינדור התוכן, כדי להסתיר את זמן האחזור של הרינדור. ה-thread של הקומפוזיציה משתמש בשיטה הזו.
  • מעבר מקביל של צינור עיבוד נתונים: הפעלת צינור עיבוד הנתונים בכמה מקומות בו-זמנית. כך הגלילה והאנימציה יכולות להיות מהירות. גם אם מתרחש עדכון ראשי של רינדור השרשורים, הגלילה והאנימציה יכולות לפעול במקביל.

תהליך דפדפן

תרשים של תהליכי העיבוד בדפדפן שמציג את הקשר בין הרינדור וההרכבה של השרשור לבין כלי העזר לשרשורים לעיבוד ולהרכבה.

  • ה-thread של העיבוד וההרכבה מגיב לקלט בממשק המשתמש של הדפדפן, מנתב קלט אחר לתהליך העיבוד הנכון, בפריסה ומצייר של ממשק המשתמש של הדפדפן.
  • כלי העזר לשרשורים בעיבוד והרכבה מריצים משימות של פענוח הקוד של תמונות וגם רסטר או פענוח קוד של חלופות.

העיבוד וה-thread של ההרכבה דומים לקוד ולפונקציונליות של תהליך רינדור הדפדפן, למעט ה-thread הראשי וה-thread הראשי משולבים יחד. במקרה הזה נדרש רק thread אחד, כי אין צורך בבידוד ביצועים ממשימות ארוכות של ה-thread הראשי, כי אין אף שרשור תוכנן.

תהליך Viz

תהליך Viz כולל את ה-thread הראשי של ה-GPU ואת ה-thread של רכיב התצוגה.

  • הרסטרים של ה-thread הראשי של GPU מציגים רשימות ופריימים של סרטונים למשבצות טקסטורה של GPU, ומשרטטים את הפריימים של הקומפוזבילי למסך.
  • ה-thread של קומפוזיטור התצוגה צובר ומבצע אופטימיזציה של הרכבה מכל תהליך רינדור, בנוסף לתהליך הדפדפן, למסגרת קומפוזבילי אחת להצגה במסך.

רסטר וציור מתרחשים בדרך כלל באותו שרשור, כי שניהם מסתמכים על משאבי GPU, וקשה לבצע שימוש מהימן עם שרשורים מרובים ב-GPU (גישה קלה יותר לשרשורים מרובים ל-GPU היא אחד מהמניעים לפיתוח תקן Vulkan החדש). ב-Android WebView יש שרשור נפרד לעיבוד ברמת מערכת ההפעלה, בגלל האופן שבו רכיבי WebView מוטמעים באפליקציית נייטיב. סביר להניח שבפלטפורמות אחרות יהיה שרשור כזה.

רכיב הקומפוזבילי של תצוגה נמצא ב-thread אחר כי הוא צריך להיות מגיב כל הזמן, ולא לחסום אף מקור אפשרי של האטה ב-thread הראשי של ה-GPU. אחת הסיבות להאטה בשרשור הראשי של ה-GPU היא קריאות לקוד שאינו Chromium, כמו מנהלי התקנים של GPU ספציפיים לספק, שעלולות להיות איטיות בדרכים שקשה לחזות מראש.

מבנה הרכיב

בכל תהליך רינדור, ראשי או שרשור קומפוזבילי, יש רכיבי תוכנה לוגיים שיוצרים אינטראקציה זה עם זה בדרכים מובנות.

עיבוד של רכיבי ה-thread הראשי

תרשים הכלי לרינדור Blink.

בכלי לעיבוד ההבהוב:

  • המקטע של עץ המסגרות המקומי מייצג את העץ של המסגרות המקומיות ואת ה-DOM בתוך מסגרות.
  • הרכיב DOM and Canvas APIs מכיל הטמעות של כל ממשקי ה-API האלה.
  • קובץ ההרצה של מחזור החיים של המסמך מבצע את השלבים בצינור עיבוד הנתונים לעיבוד, עד לשלב ההתחייבות, כולל.
  • הרכיב בדיקה של היטים ושליחה של אירועי קלט מבצע בדיקות של היטים כדי לגלות איזה רכיב DOM מטורגט על ידי אירוע, ומריץ את האלגוריתמים של שליחת אירוע הקלט ואת התנהגויות ברירת המחדל.

התזמון והפעלת לולאת האירוע לעיבוד נתונים מחליט מה להפעיל בלולאת האירוע ומתי. הוא מתזמנ את הרינדור בקצב שתואם למסך המכשיר.

תרשים של עץ המסגרות.

שברים של עצי מסגרת מקומיים הם קצת מורכבים. תזכורת: עץ מסגרת הוא הדף הראשי ורכיבי ה-iframe הצאצאים שלו, באופן רקורסיבי. פריים נחשב כמקומי לתהליך רינדור אם הוא מעובד בתהליך הזה. אחרת, הוא מרוחק.

אפשר לדמיין פריימים צבעוניים בהתאם לתהליך העיבוד שלהם. בתמונה הקודמת, העיגולים הירוקים מופיעים בכל הפריימים בתהליך רינדור אחד. המסגרות הכתומות מופיעות בשנייה והכחולה מופיעה בשלישי.

מקטע של עץ מסגרת מקומי הוא רכיב מחובר באותו צבע בעץ מסגרת. בתמונה מופיעים ארבעה עצי מסגרת מקומיים: שניים לאתר א', אחד לאתר ב' ואחד לאתר ג'. לכל עץ מסגרת מקומי יש רכיב רינדור Blink משלו. כלי רינדור ההבהוב של עץ מסגרת מקומי עשוי להיות באותו תהליך עיבוד כמו עצי מסגרת מקומיים אחרים, אבל לא בהכרח. הוא נקבע לפי האופן שבו נבחרים תהליכי העיבוד, כפי שתואר קודם.

עיבוד של מבנה השרשורים של רכיב היצירה

תרשים שמציג את רכיבי הרכיב של תהליך העיבוד.

רכיבי הקומפוזיציה של תהליך העיבוד כוללים את:

  • handler של נתונים שכולל רשימת שכבות מורכבת, רשימות של תצוגות ועצי מאפיינים.
  • הרצת מחזור חיים שמפעילה את האנימציות, הגלילה, הרכבה, רסטר ופענוח והפעלה של שלבים בצינור עיבוד הנתונים. (חשוב לזכור שהאנימציה והגלילה יכולות להתרחש גם ב-thread הראשי וגם בכלי הכתיבה).
  • ה-handler של בדיקת קלט והיטים מבצע עיבוד קלט ובדיקת היטים ברזולוציה של שכבות מורכבות, כדי לקבוע אם אפשר לרוץ תנועות גלילה בשרשור של המרכיב, ואילו אילו מעבדים צריכים להיות יעד לבדיקות.

דוגמה לארכיטקטורה בפועל

בדוגמה הזו יש שלוש כרטיסיות:

כרטיסייה 1: foo.com

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

כרטיסייה 2: bar.com

<html>
 …
</html>

כרטיסייה 3: baz.com html <html> … </html>

המבנה של התהליך, השרשור והרכיבים בכרטיסיות האלה נראה כך:

תרשים של התהליך לכרטיסיות.

נעבור על דוגמה אחת לכל אחת מארבע משימות הרינדור העיקריות. תזכורת:

  1. רינדור התוכן לפיקסלים במסך.
  2. הנפשה של אפקטים חזותיים בתוכן ממצב אחד לאחר.
  3. גוללים בתגובה לקלט.
  4. ניתוב קלט יעיל למקומות הנכונים כדי שהסקריפטים של המפתחים ומערכות משנה אחרות יוכלו להגיב.

כדי לעבד את ה-DOM שהשתנה בכרטיסייה הראשונה:

  1. סקריפט של מפתח משנה את ה-DOM בתהליך העיבוד של foo.com.
  2. כלי הרינדור של Blink מורה למרכיב שהוא צריך לבצע רינדור.
  3. הקומפוזיטור מורה ל- Viz שיש צורך בעיבוד כדי להתרחש.
  4. Viz מסמן את תחילת העיבוד בחזרה למרכיב היצירה.
  5. המרכיב מעביר את אות ההתחלה לרינדור של Blink.
  6. רכיב ההרצה של לולאת האירוע הראשי ב-thread מריץ את מחזור החיים של המסמך.
  7. ה-thread הראשי שולח את התוצאה ל-thread של המחבר.
  8. רכיב ההרצה של האירוע compositor מפעיל את מחזור החיים של ההרכבה.
  9. משימות רסטר נשלחות ל-Viz for raster (לרוב יש יותר מאחת מהמשימות האלה).
  10. Viz rasters תוכן ב-GPU.
  11. Viz מאשרת שהמשימה בוצעה בהצלחה. הערה: לעיתים קרובות Chromium לא מחכה לסיום הרסטר, ובמקום זאת משתמש במשהו שנקרא אסימון סנכרון, שצריך לפתור על ידי משימות של רשת נקודות לפני הרצת שלב 15.
  12. מסגרת קומפוזיטור נשלחת אל Viz.
  13. Viz צוברת את מסגרות הקומפוזיציה של תהליך העיבוד של foo.com, את תהליך העיבוד של ה-iframe bar.com ואת ממשק המשתמש של הדפדפן.
  14. Viz מתזמנת תיקו.
  15. Viz משרטטת את מסגרת הקומפוזביליות המצטברת למסך.

כדי להוסיף אנימציה לטרנספורמציה של CSS בכרטיסייה מספר 2:

  1. ב-thread של המרכיב של תהליך העיבוד bar.com מסמן אנימציה בלולאת האירוע של הקומפוזיטור על ידי שינוי של עצי המאפיין הקיימים. הפעולה הזו תפעיל מחדש את מחזור החיים של המרכיב. (ייתכן שמשימות של רסטר ופענוח יתרחשו, אבל הן לא מתוארות כאן).
  2. מסגרת קומפוזיטור נשלחת אל Viz.
  3. Viz צוברת את פריימים של הקומפוזבילי לתהליך העיבוד של foo.com, לתהליך העיבוד bar.com ולממשק המשתמש של הדפדפן.
  4. Viz מתזמנת תיקו.
  5. Viz משרטטת את מסגרת הקומפוזביליות המצטברת למסך.

כדי לגלול את דף האינטרנט בכרטיסייה השלישית:

  1. רצף של אירועי input (עכבר, מגע או מקלדת) מגיע לתהליך הדפדפן.
  2. כל אירוע ינותב לשרשור המחבר של תהליך העיבוד ב-baz.com.
  3. המחבר קובע אם ה-thread הראשי צריך לדעת על האירוע.
  4. אם צריך, האירוע נשלח לשרשור הראשי.
  5. ה-thread הראשי מפעיל את פונקציות האירועים של input (pointerdown, touchstar, pointermove, touchmove או wheel) כדי לראות אם המאזינים יתקשרו ל-preventDefault באירוע.
  6. ה-thread הראשי יחזיר אם preventDefault הופעל למרכיב המאגר.
  7. אם לא, אירוע הקלט נשלח בחזרה לתהליך הדפדפן.
  8. תהליך הדפדפן ממיר אותו לתנועת גלילה על ידי שילוב שלו עם אירועים אחרים מהזמן האחרון.
  9. תנועת הגלילה נשלחת שוב לשרשור עיבוד תהליך העיבוד של baz.com
  10. הגלילה מופעלת שם, ושרשור הקומפוזבילי בתהליך העיבוד של bar.com מסמן אנימציה בלולאה של האירוע compositor. לאחר מכן, הפעולה הזו משנה את היסט הגלילה בעצים של הנכסים ומריצה מחדש את מחזור החיים של המרכיב. היא גם מנחה את ה-thread הראשי להפעיל אירוע scroll (לא מוצג כאן).
  11. מסגרת קומפוזיטור נשלחת אל Viz.
  12. Viz צוברת את פריימים של הקומפוזבילי לתהליך העיבוד של foo.com, לתהליך העיבוד bar.com ולממשק המשתמש של הדפדפן.
  13. Viz מתזמנת תיקו.
  14. Viz משרטטת את מסגרת הקומפוזביליות המצטברת למסך.

כדי לנתב אירוע click בהיפר-קישור ב-iframe #two בכרטיסייה 1:

  1. אירוע input (עכבר, מגע או מקלדת) מגיע לתהליך הדפדפן. היא מבצעת בדיקת היט משוערת כדי לקבוע שתהליך העיבוד של ה-iframe bar.com אמור לקבל את הקליק ושולח אותו לשם.
  2. שרשור הקומפוזיציה של bar.com מנתב את האירוע click ל-thread הראשי ב-bar.com ומתזמן משימת רינדור event לולאה כדי לעבד אותו.
  3. מעבד אירועי הקלט לבדיקות ה-thread הראשי של bar.com כדי לקבוע על איזה רכיב DOM ב-iframe בוצע קליק, ומפעיל אירוע click כדי לצפות בסקריפטים. לא שומעים preventDefault, עוברים להיפר-קישור.
  4. אחרי טעינת דף היעד של ההיפר-קישור, מתבצע עיבוד של המצב החדש, עם שלבים שדומים לדוגמה הקודמת 'render changed DOM'. (השינויים הבאים לא מוצגים כאן).

טייק אוויי

יכול להיות שייקח הרבה זמן לזכור ולהפנים את אופן הפעולה של הרינדור.

המסקנה החשובה ביותר היא שצינור עיבוד הנתונים, באמצעות מודולריזציה קפדנית ותשומת לב לפרטים, פוצל למספר רכיבים שעומדים בפני עצמם. לאחר מכן, הרכיבים האלו פוצלו בין תהליכים ושרשורים מקבילים כדי למקסם את הביצועים שניתנים להתאמה ואת ההזדמנויות להרחבה.

לכל רכיב יש תפקיד חשוב בהפעלת הביצועים והתכונות של אפליקציות אינטרנט מודרניות.

המשיכו לקרוא על מבני הנתונים המרכזיים, שחשובים ל-RenderingNG לא פחות מרכיבי קוד.

איורים של Una Kravets.