סקירה כללית של ארכיטקטורת RenderingNG

Chris Harrelson
Chris Harrelson
X GitHub

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

משימות הרינדור מתחילה מהרמה הגבוהה ביותר ומציגה פירוט משם:

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

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

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

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

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

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

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

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

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

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

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

בפוסט הבא לא נפרט על ארטיפקטים, ונסביר עליהם בפוסט הבא: Key Data Structures (מבנים מרכזיים) של נתונים ותפקידם ב-RenderingNG.

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

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

  • ירוק: ה-thread הראשי של תהליך העיבוד
  • צהוב: מחבר תהליך העיבוד
  • כתום: תהליך Viz

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

השלבים הם:

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

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

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

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

מעבד (CPU)

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

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

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

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

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

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

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

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

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

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

שרשורים

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

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

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

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

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

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

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

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

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

תהליך הדפדפן

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

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

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

תהליך Viz

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

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

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

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

מבנה הרכיבים

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

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

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

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

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

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

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

מקטע עץ של מסגרת מקומית הוא רכיב מחובר בעל אותו צבע בעץ מסגרת. יש בתמונה ארבעה עצי מסגרת מקומיים: שניים לאתר א', אחד לאתר ב' ואחד לאתר ג'. לכל עץ מסגרת מקומי יש רכיב רינדור Blink משלו. הכלי לרינדור 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>

Tab 2: bar.com

<html>
 …
</html>

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

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

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

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

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

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

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

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

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

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

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

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

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

סיכום

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

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

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

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

תודה שקראת והמשך להתעדכן!

איורים של אונה קראבטס.