מוכן לדור הבא של תוכן אינטרנט
שמי כריס הרלסון, ואני אחראי על רינדור (המרת HTML ו-CSS לפיקסלים) ב-Blink. כבר יותר משמונה שנים, הייתי מתעמקת בתהליכי עיבוד הביצועים באינטרנט, מתוך מטרה אישית לעשות כל שביכולתי כדי להפוך את חוויית המשתמש הטובה ביותר באינטרנט לקלה, מהירה ומהימנה יותר. אני שמח לספר לך על מה שעשינו באותה תקופה כדי לפתח ארכיטקטורה חדשה ומתקדמת של מנוע עיבוד ב-Chromium. זה היה מאמץ עצום של אהבה, ואני מקווה שנהנית לשמוע על כך!
בשנת 2021 נשלים במידה רבה את תהליך התכנון, הבנייה והמשלוח של הארכיטקטורה הזו. נקרא לזה RenderingNG, מאחר שזו באמת ארכיטקטורת עיבוד מהדור הבא שהביצועים שלה טובים באופן משמעותי מאלה שקדמו לה. ה-RenderingNG מתבצע כבר שמונה שנים לפחות, ומייצג את העבודה המשותפת של מפתחי Chromium ייעודיים רבים. היא פותחת כמות עצומה של פוטנציאל לדור הבא של תוכן אינטרנט מהיר, גמיש, אמין, רספונסיבי ואינטראקטיבי. זהו גם בסיס שנראה לי שמגדיר תקן מינימלי חדש לכל מנועי העיבוד באינטרנט שעליהם המפתחים יכולים להסתמך.
זהו פוסט בבלוג הראשון בסדרה, שבו נסביר מה בנינו, למה בנינו אותו ואיך זה עובד. בפוסט הראשון הזה, אתחיל עם:
- היעד שלנו בכוכב הצפון.
- פירמידת ההצלחה: העקרונות שמנחים את העבודה שלנו ודוגמאות לעקרונות האלה בפועל.
- התכונות והיכולות שמאפשרות עיבוד NG.
- סקירה כללית על מרכיבי הפרויקט העיקריים של RenderingNG.
כוכב צפון
היעד של כוכב הצפון שמניע את RenderingNG הוא שההטמעה של מנוע הדפדפן והעושר של ממשקי ה-API לעיבוד תמונה לא אמורים להגביל את חוויית המשתמש באינטרנט.
לא צריך לדאוג מבאגים בדפדפן שיהפכו את התכונות לבלתי אמינות או יגרמו לשיבושים ברינדור של האתר.
לא אמורים להיות צוקי ביצועים מסתוריים. בנוסף, לא תצטרכו לעקוף את התכונות המובנות החסרות.
זה אמור לעבוד.
אני חושב ש-RenderingNG הוא צעד ענק לקראת היעד של כוכב הצפון. לפני ה-RenderingNG יכולנו (וכן) להוסיף תכונות רינדור ולשפר את הביצועים, אבל התקשו לנו להפוך את התכונות האלה למהימנות למפתחים, והיו עלו הרבה צוקים בביצועים. עכשיו יש לנו ארכיטקטורה שמשביתה באופן שיטתי חלק גדול מהבעיות האלה, והיא גם מבטלת את החסימה של תכונות מתקדמות שלא נחשבו למעשיות בעבר. התיוג האוטומטי:
- כולל תכונות ליבה יציבות ביותר בשילובים שונים של פלטפורמה, מכשיר ומערכת הפעלה.
- בעל ביצועים אמינים וצפויים.
- מיקסום השימוש ביכולות החומרה (ליבות, GPU, רזולוציית מסך, קצב רענון, ממשקי API של רשת נקודות ברמה נמוכה).
- מבצע רק את העבודה הנדרשת להצגת תוכן גלוי.
- יש תמיכה מובנית בתבניות עיצוב חזותיות נפוצות, אנימציה ועיצוב אינטראקציות.
- מספק ממשקי API למפתחים לניהול קל של עלויות הרינדור.
- מספק נקודות הארכה של צינור עיבוד נתונים עבור תוספים למפתחים.
- אופטימיזציה לכל התוכן - HTML, CSS, 2D Canvas, קנבס בתלת-ממד, תמונות, וידאו וגופנים.
השוואה למנועי רינדור אחרים בדפדפן
Gecko ו-Webkit יישמו גם את רוב התכונות הארכיטקטוניות שמתוארות בפוסטים האלה בבלוג, ובמקרים מסוימים הוסיפו אותן לפני Chromium. וזה מעולה! כל דפדפן שהופך למהיר יותר ואמין יותר הוא סיבה לחגיגה שיש לו השפעה אמיתית, אבל המטרה הסופית היא לקדם את עקרונות הבסיס של כל הדפדפנים, כדי שהמפתחים יוכלו לסמוך עליו.
פירמידת ההצלחה
הפילוסופיה שלי היא שהצלחה היא התוצאה של השגת אמינות ראשונה, לאחר מכן ביצועים ניתנים להרחבה, ולבסוף יכולת הרחבה.
כמו בפירמידה בעולם האמיתי, כל רמה מספקת בסיס יציב בהכרח לרמה שלמעלה.
אמינות
אם אפשר באמת ליהנות מחוויות משתמש עשירות ומורכבות, הדבר הראשון שאנחנו צריכים הוא פלטפורמה חזקה. התכונות העיקריות והקווים הבסיסיים צריכים לפעול כמו שצריך, ולהמשיך לפעול לאורך זמן. באותה מידה חשוב שהתכונות האלה יפעלו היטב, ולא יהיו להן התנהגות מוזרה בשוליים או באגים.
לכן, האמינות היא החלק החשוב ביותר בעיבוד של ה-RenderingNG. ואמינות היא תוצאה של בדיקות טובות, לולאות משוב איכותיות, מדדים ודפוסי עיצוב תוכנה.
כדי לתת מושג עד כמה לדעתי האמינות חשובה, השקענו את רוב שמונה השנים האחרונות בחלק הזה. קודם כל, פיתחנו ידע מעמיק על המערכת – למידה מדוחות איתור באגים ותיקון הנקודות החלשות, אתחול בדיקות מקיפות והבנת צורכי הביצועים של אתרים ומגבלות הביצועים של Chromium. לאחר מכן, עיצבנו והשקנו דפוסי עיצוב ומבני נתונים מרכזיים באופן זהיר והדרגתי. רק אז היינו מוכנים להוסיף פרימיטיבים מהדור הבא לעיצוב רספונסיבי, ליכולת התאמה ולהתאמה אישית של הרינדור.
זה לא אומר ששום דבר לא השתפר ב-Chromium באותו הזמן. למעשה, ההפך הוא הנכון. בשנים האלה ראינו עלייה יציבה ומתמשכת במהימנות ובביצועים, כשביצענו מחדש את הקוד והשקנו כל שיפור באופן מפורט.
בדיקה ומדדים
במהלך 8 השנים האחרונות הוספנו עשרות אלפי בדיקות של יחידות, ביצועים ושילוב. בנוסף, פיתחנו מדדים מקיפים שמודדים היבטים רבים של אופן הרינדור של Chromium בבדיקות מקומיות, במדדי ביצועים של ביצועים, ובטבע באתרים אמיתיים, עם משתמשים ומכשירים אמיתיים.
אבל לא משנה עד כמה עיבוד ה-RenderingNG (או של אותו מנוע רינדור של דפדפן אחר) נהדר, עדיין לא יהיה קל לפתח אותו באינטרנט אם יש הרבה באגים או הבדלים בהתנהגות בין דפדפנים. כדי לפתור את הבעיה, אנחנו גם מגדילים את השימוש בבדיקות של פלטפורמת האינטרנט. כל אחת מהבדיקות האלה מאמתת דפוס שימוש בפלטפורמת האינטרנט שכל הדפדפנים צריכים לרצות לעבור. אנחנו גם עוקבים מקרוב אחרי המדדים כדי לעבור יותר בדיקות לאורך זמן ולשפר את התאימות לליבה.
הבדיקות של פלטפורמת האינטרנט הן שיתוף פעולה. לדוגמה, מהנדסי Chromium הוסיפו רק כ-10% מסך בדיקות ה-WPT לתכונות של CSS. שאר הבדיקות הן על-ידי ספקי דפדפנים אחרים, שותפים עצמאיים וכותבי מפרטים. דרוש כפר כדי להעלות את יכולת הפעולה ההדדית באינטרנט!
דפוסים טובים בעיצוב תוכנה
אספקה אמינה של תוכנה איכותית היא, מצידה, הרבה יותר קל אם הקוד קל להבנה ומתוכנן באופן שמצמצם את הסיכוי לבאגים. בפרסומים הבאים נשתף עוד הרבה פרטים על עיצוב התוכנה של RenderingNG.
ביצועים שניתנים להתאמה
יצירה של ביצועים מעולים – ביחס לממדים של מהירות, זיכרון ושימוש בכוח, היא ההיבט החשוב הבא ב-RenderingNG. אנחנו רוצים שהאינטראקציות עם כל אתרי האינטרנט יהיו חלקות ורספונסיביות, אבל לא פוגע ביציבות המכשיר.
אבל אנחנו לא רוצים רק להשיג ביצועים, אנחנו רוצים להשיג ביצועים ניתנים להתאמה - ארכיטקטורה עם ביצועים טובים ואמינים במכונות בסיסיות ויוקרתיות, ובכל פלטפורמות ההפעלה. אני מכנה את ההרחבה הזו, תוך ניצול כל היתרונות שמכשיר החומרה יכול להשיג, והתאמתה - הגברת היעילות והפחתת הביקוש למערכת בעת הצורך.
כדי להשיג את המטרה הזו, היינו צריכים להשתמש באופן מקסימלי בשמירה במטמון, בבידוד ביצועים ובהאצת חומרה של GPU. נבחן כל אחד מהם בנפרד. כדי להמחיש את זה, נחשוב על האופן שבו כל אחד מהם תורם לביצועים של אינטראקציה חשובה אחת ביותר בדפי אינטרנט: גלילה.
שמירה במטמון
בפלטפורמת ממשק משתמש דינמית ואינטראקטיבית כמו האינטרנט, שמירה במטמון היא הדרך החשובה ביותר לשיפור הביצועים באופן משמעותי. הסוג המוכר ביותר של שמירה במטמון בדפדפן הוא מטמון ה-HTTP, אבל ברינדור יש גם הרבה מטמון. המטמון החשוב ביותר לגלילה הוא המרקמים של ה-GPU ורשימות תצוגה, שמאפשרים גלילה מהירה במיוחד תוך צמצום התרוקנות הסוללה ועבודה טובה במגוון מכשירים.
שמירה במטמון עוזרת לחיי הסוללה ולקצב הפריימים של האנימציה בזמן הגלילה, אבל חשוב עוד יותר זה לבטל את החסימה של בידוד הביצועים מה-thread הראשי.
בידוד ביצועים
במחשבים שולחניים מודרניים, אין צורך לדאוג שאפליקציות ברקע יאטו את המחשב שבו אתם עובדים. הסיבה לכך היא של ריבוי משימות מניעתי, שמהווה סוג של בידוד ביצועים: כדי לוודא שמשימות עצמאיות לא מאטות זו את זו.
הדוגמה הטובה ביותר לבידוד ביצועים באינטרנט היא שימוש בגלילה. גם באתרים עם הרבה JavaScript איטי, הגלילה יכולה להיות חלקה מאוד כי היא פועלת בשרשור אחר שלא חייב להיות תלוי ב-JavaScript ובשרשור הפריסה. השקענו מאמץ רב בעיבוד NG כדי להבטיח שכל גלילה אפשרית תהיה מחולקת לשרשורים, באמצעות שמירה במטמון מעבר לרשימת תצוגה, במצבים מורכבים יותר. לדוגמה, קוד לייצוג אלמנטים שנמצאים במיקום קבוע ובמיקום דביק, פונקציות event listener פסיביות ורינדור טקסט באיכות גבוהה.
האצה של GPU
יחידת ה-GPU מזרזת באופן משמעותי את היצירה של פיקסלים וציור במסך - במקרים רבים ניתן לצייר כל פיקסל במקביל לכל פיקסל אחר, וכתוצאה מכך להגביר את המהירות באופן משמעותי. רכיב מרכזי ב-RenderingNG הוא רסטר של GPU וניתן לצייר בכל מקום. זה משתמש ב-GPU בכל הפלטפורמות ובכל המכשירים, כדי להאיץ במיוחד את העיבוד והאנימציה של תוכן אינטרנט. הדבר חשוב במיוחד במכשירים פשוטים או במכשירים מתקדמים, שלרוב יש GPU הרבה יותר משוכלל מאשר בחלקים אחרים של המכשיר.
יכולת הרחבה: הכלים שמתאימים לביצוע המשימה
ברגע שהשגנו את האמינות והביצועים שניתן להתאים, עכשיו אנחנו מוכנים לבנות מעל מגוון כלים שיעזרו למפתחים להרחיב את החלקים המובנים של HTML, CSS ולוח הציור, בדרכים שלא לוותר על הביצועים והאמינות האלה.
התכונות האלה כוללות ממשקי API מובנים ונחשפים ל-JavaScript, לשימוש בתרחישים מתקדמים של עיצוב רספונסיבי, רינדור Progressive, חלקות ומהירות תגובה, ורינדור בשרשור.
ממשקי ה-API הבאים באינטרנט הפתוחים הבאים, שהופעלו על ידי Chromium, התאפשרו על ידי RenderingNG, ובעבר נחשבו בלתי אפשריים.
כל הפיתוחים האלה פותחו תוך שימוש במפרטים פתוחים ובשיתוף פעולה עם שותפי אינטרנט פתוחים – מהנדסים בדפדפנים אחרים, מומחים ומפתחי אינטרנט. בפוסטים הבאים בבלוג, נתעמק בכל אחד מהנושאים ונסביר איך RenderingNG מאפשר אותם.
- content-visibility: מאפשרת לאתרים להימנע בקלות מעיבוד העבודה לתוכן שלא מופיע במסך, ומעיבוד במטמון של תצוגות אפליקציות בדף יחיד שלא מוצגות כרגע.
- OffscreenCanvas: מאפשרת לרינדור של בד קנבס (ב-2Dcanvas API וגם ב-WebGL) לרוץ ב-thread נפרד, וכך להשיג ביצועים מעולים. הפרויקט הזה הוא גם אבן דרך חשובה נוספת באינטרנט – הוא ממשק ה-API הראשון באינטרנט שמאפשר ל-JavaScript (או WebAssembly!) לעבד מסמך יחיד של דף אינטרנט מכמה שרשורים.
- שאילתות על קונטיינר: מאפשרת לרכיב יחיד לפרוס את עצמו באופן רספונסיבי, לבטל חסימה של מגוון שלם של רכיבי פלאגין והפעלה (כרגע זו הטמעה ניסיונית).
- בידוד של המקור: מאפשר לאתרים להגדיר בידוד טוב יותר בין מסגרות iframe.
- worklets של צבע ללא שרשור ראשי: נותנים למפתחים דרך להרחיב את אופן הצביעה של אלמנטים, באמצעות קוד שרץ בשרשור המאחד.
בנוסף לממשקי API מפורשים לאינטרנט, RenderingNG אפשר לנו לספק כמה "תכונות אוטומטיות" משמעותיות מאוד שמועילות לכל האתרים:
- בידוד אתר: הוספת iframes ממקורות שונים בתהליכים שונים של מעבד (CPU) כדי לשפר את האבטחה והבידוד הביצועים.
- Vulkan, D3D12 ו-Metal: מנצלים את ממשקי ה-API ברמה נמוכה יותר שמשתמשים ב-GPU בצורה יעילה יותר מאשר ב-OpenGL.
- אנימציות מורכבות יותר: SVG, צבע רקע.
תכונות נוספות שאנחנו שמחים בקרוב לראות שהחסימה שלהן בוטלה על ידי RenderingNG:
- אנימציות שמקושרות לגלילה.
- DOM מוסתר, אך ניתן לחיפוש ונגיש.
- מעברים של רכיבים משותפים.
- פריסה מותאמת אישית.
- איחוד ללא שרשור ראשי, פענוח שרשורים וחיבור.
פרויקטים מרכזיים שמהם מורכבת RenderingNG
בהמשך מופיעה רשימת הפרויקטים המרכזיים ב-RenderingNG. הפוסטים הבאים בבלוג יתעמקו בכל אחד מהם.
CompositeAfterPaint
שילוב של סגנון, פריסה וצבע, משפר מאוד את האמינות ואת הביצועים הצפויים, את התפוקה ואת התפוקה, ואת השימוש בפחות זיכרון בלי לפגוע בביצועים. הוא התחיל ב-2014 ויסתיים השנה.
| שנה | ההתקדמות |
|---|---|
| 2015 | רשימות של תצוגת משלוחים. |
| 2017 | שליחת ביטול תוקף חדש. |
| 2018 | עץ של נכס אונייה חלק 1. |
| 2019 | עץ של נכס אונייה חלק 2. |
| 2021 | משלוח הפרויקט הושלם. |
LayoutNG
שכתוב יסודי של כל האלגוריתמים של הפריסה, לשיפור האמינות והביצועים הצפויים. התהליך התחיל ב-2016 ומתוכנן להסתיים השנה.
| שנה | ההתקדמות |
|---|---|
| 2019 | זרימה של בלוק ספינה. |
| 2020 | ספינה גמישה, עריכה. |
| 2021 | שולחים את כל השאר. |
BlinkNG
ניקוי וארגון מחדש של מערכת מנוע העיבוד Blink באופן שיטתי לשלבי צינור מופרדים נקיים. כך אפשר לשמור טוב יותר במטמון, ליהנות מאמינות גבוהה יותר ולהשתמש בתכונות של התחברות מחדש או עיבוד מאוחר, כמו חשיפת תוכן ושאילתות בקונטיינרים. היא החלה ב-2014 והצטברה שיפורים לתהליכי עבודה מצטברים, והיא נמשכת מאז. התהליך יושלם ב-2021.
האצת GPU בכל מקום
מאמץ ארוך טווח להשקת רסטר של GPU, ציור ואנימציה בכל הפלטפורמות, כל הזמן. האצה של GPU מספקת האצה עצומה עבור רוב התוכן, כי ניתן לעבד כל פיקסל במקביל. זו גם שיטה יעילה לשיפור הביצועים במכשירים פשוטים, שבדרך כלל עדיין יש בהם GPU. התהליך התחיל ב-2014 והושלם ב-2020.
| שנה | ההתקדמות |
|---|---|
| 2014 | תמיכה בלוח הציור. נשלחת כשאת בוחרת לשתף תוכן ב-Android. |
| 2016 | לשלוח ב-Mac. |
| 2017 | יחידת ה-GPU נמצאת בשימוש ביותר מ-60% מהצפיות בדפים ב-Android. |
| 2018 | אתם יכולים לשלוח אותן ב-Windows, ב-ChromeOS וב-Android Go. |
| 2019 | יצירת רסטר של GPU בשרשור. |
| 2020 | שליחת שאר התוכן ב-Android. |
גלילה בשרשור, אנימציות ופענוח
מאמץ ארוך טווח להעביר את כל הגלילה, האנימציות שלא גורמות לפריסה ופענוח של התמונות מהשרשור הראשי. הוא התחיל ב-2011 והוא נמשך כל הזמן.
| שנה | ההתקדמות |
|---|---|
| 2011 | תמיכה ראשונית בגלילה ובאנימציה בשרשור. |
| 2015 | דחיסת שכבות. |
| 2016 | גלילת גלישה אוניברסלית. |
| 2017 | התמונה מפענחת בשרשור של קומפוזיטור. |
| 2018 | אנימציות של תמונות בשרשור של קומפוזיטור. |
| 2020 | הרכב תמיד עם מיקום קבוע. |
| 2021 | אחוז אנימציות של טרנספורמציה, אנימציות SVG. |
ויז
תהליך מרכזי של רסטר וציור ב-Chromium שמגדיל את התפוקה, ממטב את הזיכרון ומאפשר שימוש אופטימלי ביכולות החומרה. יש גם יתרונות נוספים שגלויים פחות למפתחי אתרים אבל מאוד גלויים למשתמשים, למשל ביטול החסימה של בידוד של אתר והפרדת צינור עיבוד הנתונים לעיבוד מרינדור ממשק המשתמש של הדפדפן. התהליך התחיל ב-2016 ויסתיים ב-2021.
| שנה | ההתקדמות |
|---|---|
| 2018 | OOP-R נשלחת ב-Android, ב-Mac וב-Windows. |
| 2019 | OOP-D נשלחה. OOP-R נשלחת לכל מקום (למעט קנבס). SkiaRenderer נשלח ב-Linux. |
| 2020 | SkiaRenderer נשלח למכשירי Windows ו-Android. Vulkan נשלח ב-Android. |
| 2021 | SkiaRenderer נשלח ל-Mac (ובקרוב גם ל-ChromeOS). |
הגדרות של מונחים שמופיעים בתרשים שלמעלה:
- אופס-D
- מחבר התצוגה מחוץ לתהליך. איחוד התצוגה הוא אותו סוג של פעילות כמו רכיב מערכת ההפעלה. מחוץ לתהליך פירושו ביצוע בתהליך Viz במקום תהליך העיבוד של דף האינטרנט או תהליך ממשק המשתמש של הדפדפן.
- OOP-R
- רסטר מחוץ לתהליך. Raster ממיר רשימות תצוגה לפיקסלים. מחוץ לתהליך פירושו ביצוע בתהליך Viz ולא בתהליך העיבוד של דף האינטרנט.
- SkiaRenderer
- הטמעה חדשה של מחבר התצוגה, שיכולה לתמוך בביצוע במגוון ממשקי API בסיסיים של GPU כמו Vulkan, D3D12 או Metal.
עיבוד בשרשור עם משבצות ועיבוד מואץ של אזור העריכה
זהו הפרויקט שיצר את החלקים הארכיטקטוניים שאפשרו את OffscreenCanvas. הוא התחיל ב-2015 ויסתיים ב-2021.
| שנה | ההתקדמות |
|---|---|
| 2018 | משלוח אל מחוץ למסך. |
| 2019 | שליחת ImageBitmapRenderingContext. |
| 2021 | משלוח OOP-R. |
VideoNG
מאמץ ארוך טווח לספק הפעלת וידאו יעילה, אמינה ואיכותית באינטרנט.
| שנה | ההתקדמות |
|---|---|
| 2014 | נוספה מסגרת רינדור המבוססת על Mojo. |
| 2015 | נשלחו אפשרויות של חמאה מהפרויקט ושכבות-על של סרטונים לעיבוד וידאו חלק יותר. |
| 2016 | נשלחו צינורות עיבוד נתונים מאוחדים לפענוח ולעיבוד של Android ומחשב. |
| 2017 | נשלח HDR ורינדור וידאו עם תיקונים לצבע. |
| 2018 | נשלח צינור עיבוד נתונים לפענוח סרטונים מבוסס Mojo. |
| 2019 | צינור עיבוד נתונים לעיבוד וידאו שנשלח על סמך פני השטח. |
| 2021 | נשלחה תמיכה בעיבוד תוכן מוגן 4K ב-ChromeOS. |
הגדרות של מונחים שמופיעים בתרשים שלמעלה:
- מוג'ו
- מערכת משנה של IPC מהדור הבא ל-Chromium.
- פלטפורמה
- קונספט שהוא חלק מעיצוב הפרויקט של Viz.
סיכום
מאוד שמחתי לראות את קצב השיפור ברינדור באינטרנט וב-Chromium. אני צופה שהקצב ימשיך להתאץ בשנים הקרובות, כשאנחנו יכולים לבנות על הבסיס היציב של ה-RenderingNG.
כדאי לעקוב אחרי פוסטים עתידיים רבים נוספים עם הרבה יותר פרטים על הארכיטקטורה החדשה, על האופן שבו היא נראתה ועל האופן שבו היא פועלת.
תמונה של מכשירים מאת אייריק סולהיים ב-UnFlood
איורים של אונה קראבטס.