ארכיטקטורת RenderingNG

Chris Harrelson
Chris Harrelson
X GitHub

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

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

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

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

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

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

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

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

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

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

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

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

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

השלבים הם:

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

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

הרינדור של ממשק המשתמש של הדפדפן לא מתואר ישירות כאן, אבל אפשר להתייחס אליו כאל גרסה פשוטה יותר של אותו צינור עיבוד נתונים (ולמעשה, ההטמעה של חלק גדול מהקוד משותפת). סרטון (גם לא מוצג באופן ישיר) בדרך כלל מעובד עם קוד עצמאי שמפענח פריימים למשבצות טקסטורה של 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.
  • בשרשור של הקומפוזיטור מתבצע עיבוד של אירועי קלט, מבצעת גלילה ואנימציות של תוכן מהאינטרנט, שמחשב שכבות אופטימלי של תוכן אינטרנט, וקואורדינטות פענוח קוד של תמונות, לעבודות של צבע ומשימות של רסטר.
    • עוזרים ל-threads של קומפוזיטור לתאם משימות של Viz Raster, ולהריץ משימות של פענוח קוד של תמונות, worklet של ציורים ו-fallback raster.
  • פענוח של שרשורים של מדיה, demuxer או פלט אודיו, לעבד ולסנכרן את שידורי הווידאו והאודיו. (חשוב לזכור שהסרטון מופעל במקביל לצינור העיבוד הראשי).

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

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

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

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

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

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

תהליך דפדפן

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

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

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

תהליך Viz

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

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

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

מחבר התצוגה נמצא ב-thread אחר כי הוא צריך להיות מגיב כל הזמן, ולא לחסום מקור אפשרי של האטה ב-thread הראשי של ה-GPU. אחת הסיבות להאטה ב-thread הראשי של ה-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 מסמן אנימציה בלולאת האירועים של הקומפוזיטור על ידי שינוי של עצי המאפיין (property) הקיימים. הפעולה הזו תפעיל מחדש את מחזור החיים של המרכיב. (ייתכן שמשימות של רסטר ופענוח יתרחשו, אבל הן לא מתוארות כאן).
  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 תהליך העיבוד מסמן אנימציה בלולאת האירועים של המרכיב שלה. לאחר מכן, הפעולה הזו משנה את היסט הגלילה בעצים של הנכסים ומריצה מחדש את מחזור החיים של המרכיב. היא גם מנחה את ה-thread הראשי להפעיל אירוע scroll (לא מוצג כאן).
  11. מסגרת קומפוזיטור נשלחת אל Viz.
  12. Viz צוברת את פריימים של הקומפוזבילי בתהליך העיבוד של foo.com, תהליך העיבוד של bar.com וממשק המשתמש של הדפדפן.
  13. Viz מתזמנת תיקו.
  14. Viz משרטטת את מסגרת הקומפוזביליות המצטברת למסך.

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

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

טייק אוויי

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

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

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

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

איורים של Una Kravets.