ארכיטקטורת RenderingNG

Chris Harrelson

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

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

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

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

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

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

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

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

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

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

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

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

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

השלבים הם:

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

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

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

מבנה התהליך והחוט

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

תהליכי מעבד (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 רק תהליך רינדור אחד.

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

שרשורים

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

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

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

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

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

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

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

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

תהליך הדפדפן

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

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

תהליך היצירה של התצוגה החזותית

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

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

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

מבנה הרכיבים

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

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

ב-Blink Renderer:

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

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

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

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

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

מבנה השרשור של עיבוד הרינדור של המלחין

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

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

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

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

כרטיסייה 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. Animate של אפקטים חזותיים בתוכן ממצב אחד למצב אחר.
3. גלילה בתגובה להזנת נתונים.
4. ניתוב קלט יעיל למקומות הנכונים כדי שהסקריפטים של המפתחים ומערכות משנה אחרות יוכלו להגיב.

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

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

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

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

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

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

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

כדי לנתב אירוע click בהיפר-קישור ב-iframe מספר שתיים בכרטיסייה אחת:

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

סיכום

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

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

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

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

---

איורים של Una Kravets.