מוכנים לדור הבא של תוכן באינטרנט
RenderingNG הוא הדור הבא של ארכיטקטורת הרינדור, ויש לה ביצועים טובים מאוד בהשוואה למה שהיה לפני כן. RenderingNG נבנה לפני יותר משמונה שנים ומייצג את העבודה המשותפת של מפתחי Chromium ייעודיים. הוא פותח בפניכם פוטנציאל עצום לתוכן אינטרנט מהיר, גמיש, אמין, רספונסיבי ואינטראקטיבי.
![שרטוט של הרכיבים השונים ב-RenderingNG](https://developer.chrome.google.cn/static/docs/chromium/renderingng/image/sketch-the-different-ele-d9f18c1bd6186.jpg?authuser=0000&hl=he)
כאן תוכלו ללמוד מה פיתחנו, למה יצרנו אותו ואיך הוא עובד.
יעד של כוכב צפון
היעד שמניע את הרינדור של RenderingNG בכוכב הצפון הוא שההטמעה של מנוע הדפדפן והעושר של ממשקי ה-API לרינדור לא אמורים להשפיע על חוויית המשתמש באינטרנט.
לא צריך לחשוש מבאגים בדפדפן שיגרמו לתכונות לא אמינות או יגרמו לשיבושים בעיבוד של האתר.
לא אמורים להיות בו צוקי ביצועים מסתוריים. בנוסף, לא צריך לעקוף את התכונה החסרה בתכונות מובנות.
זה פשוט אמור לעבוד.
עיבוד ה-NG הוא צעד ענק לקראת היעד הזה של כוכב הצפון. לפני RenderingNG, יכולנו להוסיף (ועשינו) תכונות רינדור ולשפר את הביצועים, אבל התקשו להפוך את התכונות האלה למהימנות למפתחים, והיו הרבה צוקים בביצועים. עכשיו יש לנו ארכיטקטורה שמסוגלת באופן שיטתי רבות מהבעיות האלה, וגם מבטלת את החסימה של תכונות מתקדמות שקודם לא נחשבו מעשיות. התיוג האוטומטי:
- כולל תכונות ליבה שלמות בשילובים שונים של פלטפורמות, מכשירים ומערכת הפעלה.
- יש ביצועים אמינים ואמינים.
- שימוש מקסימלי ביכולות החומרה (ליבות, GPU, רזולוציית מסך, קצבי רענון, ממשקי API ברמה נמוכה של רסטר).
- מבצע רק את העבודה הנדרשת כדי להציג תוכן גלוי.
- יש תמיכה מובנית בתבניות עיצוב חזותיות נפוצות, אנימציה ואינטראקציות.
- מספקת ממשקי API למפתחים כדי לנהל בקלות עלויות רינדור.
- מספקת נקודות הארכה לצינור עיבוד נתונים לתוספים למפתחים.
- אופטימיזציה של כל התוכן – HTML, CSS, בד ציור דו-ממדי, קנבס תלת-ממדי, תמונות, סרטונים וגופנים.
השוואה למנועי עיבוד אחרים בדפדפנים
שממית ו-Webkit גם הטמיעו את רוב אותן תכונות ארכיטקטוניות שמתוארות בפוסטים בבלוג האלה, ובמקרים מסוימים אפילו נוספו אותן לפני Chromium.
כל דפדפן שפועל מהר יותר ואמין יותר הוא סיבה לחגיגה ויש לו השפעה אמיתית. המטרה האולטימטיבית היא לקדם את הבסיס לכל הדפדפנים, כדי שהמפתחים יוכלו להסתמך על זה.
הפירמידה של ההצלחה
הפילוסופיה שלי היא שהצלחה היא התוצאה הראשונה של השגת אמינות, לאחר מכן ביצועים ניתנים להרחבה, ולבסוף הרחבה.
בדומה לפירמידה בעולם האמיתי, כל רמה מספקת בסיס קבוע לרמה שמעליה.
אמינות
אם יש בכלל אפשרות לאפשר חוויות משתמש עשירות ומורכבות, הדבר הראשון שאנחנו צריכים הוא פלטפורמה יציבה ויציבה. התכונות העיקריות והיסודות חייבים לפעול בצורה תקינה ולהמשיך לפעול לאורך זמן. לא פחות חשוב שהתכונות האלה יהיו מורכבות היטב ולא יהיו להן התנהגות מוזרה של מקרי קצה או באגים.
לכן, אמינות היא החלק החשוב ביותר ב-RenderingNG. האמינות היא התוצאה של בדיקות טובות, לולאות משוב איכותיות, מדדים ודפוסי תכנון תוכנה.
כדי להבין עד כמה חשובה לדעתי האמינות, דחינו את רוב שמונה השנים האחרונות רק על החלק הזה. ראשית, יצרנו היכרות עמוקה עם המערכת – למידה מדוחות איתור באגים במקומות שבהם היו נקודות החולשה ותיקון שלהן, אתחול בדיקות מקיפות והבנת צורכי הביצועים של אתרים ומגבלות של ביצועי Chromium. לאחר מכן תכננו בקפידה ובאופן הדרגתי והשקנו תבניות עיצוב מרכזיות ומבני נתונים. רק אז יכולנו להוסיף פרימיטיביים מהדור הבא לעיצוב רספונסיבי, למדרגיות ולהתאמה אישית של עיבוד.
זה לא אומר שלא נשפרו שום דבר במהלך התקופה הזו ב-Chromium. למעשה, ההפך הוא נכון! בשנים האלה חלה עלייה יציבה וממושכת באמינות ובביצועים, אחרי שבדקנו מחדש והשקנו כל שיפור שלב אחרי שלב.
בדיקה ומדדים
ב-8 השנים האחרונות הוספנו עשרות אלפי בדיקות של יחידות, ביצועים ואינטגרציה. בנוסף, פיתחנו מדדים מקיפים שמודדים היבטים רבים של אופן הפעולה של הרינדור של Chromium בבדיקות מקומיות, בבנצ'מרקים של ביצועים ובטבע באתרים אמיתיים, עם משתמשים ומכשירים אמיתיים.
אבל לא משנה עד כמה הוא RenderingNG (או מנוע עיבוד אחר של דפדפן אחר), עדיין לא יהיה קל לפתח אותו לאינטרנט אם יש הרבה באגים או הבדלים בהתנהגות בין דפדפנים. כדי למנוע את זה, אנחנו גם מגדילים את השימוש ב-Web Platform Tests. כל אחת מהבדיקות האלה מאמתת דפוס שימוש של פלטפורמת האינטרנט שכל הדפדפנים אמורים לעבור. אנחנו גם עוקבים מקרוב אחרי המדדים כדי לעבור יותר בדיקות לאורך זמן ולשפר את התאימות הבסיסית.
בדיקות פלטפורמת אינטרנט הן מאמץ משותף. לדוגמה, מהנדסי Chromium הוסיפו רק כ-10% מסך בדיקות ה-WPT לתכונות של CSS. את השאר תורמים ספקי דפדפנים אחרים, שותפים עצמאיים וכותבי מפרטים. נדרש מהכפר להקים את רשת האינטרנט תוך נקיטת פעולה הדדית!
![בדיקות שעוברות במנועים שונים](https://developer.chrome.google.cn/static/docs/chromium/renderingng/image/tests-passing-different-f52de78b28101.png?authuser=0000&hl=he)
תבניות עיצוב טובות לתוכנה
כתוצאה מכך, הרבה יותר קל הרבה להבין תוכנה איכותית אם הקוד קל להבנה, ומעוצב באופן שמצמצם את הסיכוי לבאגים. נפרסם עוד מידע על עיצוב התוכנה של RenderingNG בפוסטים הבאים בבלוג.
ביצועים שניתנים להרחבה
השגת ביצועים מעולים – מבחינת המהירות, הזיכרון והשימוש בחשמל – היא ההיבט החשוב הבא ב-RenderingNG. אנחנו רוצים שהאינטראקציות עם כל אתרי האינטרנט יהיו חלקות ורספונסיביות, אבל בלי לפגוע ביציבות של המכשיר.
אבל אנחנו לא רוצים רק את הביצועים, אנחנו רוצים גם ביצועים בקנה מידה נרחב – ארכיטקטורה שפועלת בצורה אמינה במכונות מתקדמות ובמכונות מתקדמות, ובכל פלטפורמות של מערכות הפעלה. אני קורא להם לבצע את ההתאמה לעומס (scaling) - ניצול של כל מה שמכשיר החומרה יכול להשיג, והפחתה של קנה המידה - שיפור היעילות והפחתת הביקוש במערכת במקרה הצורך.
כדי להגיע לשם, היינו צריכים לנצל באופן מקסימלי את השמירה במטמון, את הבידוד של הביצועים ואת האצת החומרה של GPU. נתייחס לכל אחת מהן בנפרד. וכדי להמחיש את ההקשר, נבחן איך כל אחת מהן תרמת לביצועים של אינטראקציה אחת חשובה במיוחד בדפי אינטרנט: גלילה.
שמירה במטמון
בפלטפורמת ממשק משתמש דינמית ואינטראקטיבית, כמו האינטרנט, השמירה במטמון היא הדרך החשובה ביותר לשפר את הביצועים באופן דרמטי. הסוג המוכר ביותר של שמירה במטמון בדפדפן הוא המטמון של ה-HTTP, אבל בעיבוד יש גם הרבה מטמון. המטמון החשוב ביותר לגלילה הוא רשימות תצוגה ומרקמים של ה-GPU במטמון, שמאפשרים הגלילה מהירה במיוחד ולצמצם את התרוקנות הסוללה ועבודה טובה במגוון מכשירים.
שמירה במטמון עוזרת להאריך את חיי הסוללה ואת קצב הפריימים של האנימציה לצורך גלילה, אבל חשוב יותר להקפיד לבטל את החסימה של בידוד הביצועים מהשרשור הראשי.
בידוד ביצועים
במחשבים שולחניים מודרניים, אף פעם לא צריך לחשוש שאפליקציות ברקע יאטו את זמן העבודה שבו אתם עובדים. הסיבה לכך היא ריבוי משימות לפני פסילה, שהוא בעצם סוג של בידוד ביצועים: כדי שמשימות עצמאיות לא יאטו אחת את השנייה.
באינטרנט, הדוגמה הטובה ביותר לבידוד ביצועים היא גלילה. גם באתרים עם הרבה JavaScript איטי, הגלילה עשויה להיות חלקה מאוד כי היא פועלת בשרשור אחר שלא חייב להיות תלוי ב-JavaScript ובשרשור הפריסה. השקענו מאמץ רב ב-RenderingNG כדי להבטיח שכל גלילה אפשרית תהיה משורשרת באמצעות שמירה במטמון, שנמצאת הרבה מעבר לרשימת תצוגה למצבים מורכבים יותר. לדוגמה: קוד שמייצג אלמנטים במיקום קבוע ודביק, פונקציות event listener פסיביות ורינדור טקסט באיכות גבוהה.
הגברת מהירות ה-GPU
ה-GPU מאפשר ליצור פיקסלים ולצייר על המסך במהירות רבה יותר — במקרים רבים ניתן למשוך כל פיקסל במקביל לכל פיקסל אחר, וכתוצאה מכך יש עלייה אדירה במהירות. רכיב מרכזי ב-RenderingNG הוא GPU raster וציור בכל מקום. פעולה זו משתמשת ב-GPU בכל הפלטפורמות ובכל המכשירים, כדי להאיץ את העיבוד והאנימציה של תוכן אינטרנט. הדבר חשוב במיוחד במכשירים פשוטים או במכשירים מתקדמים מאוד, שלרוב יש בהם GPU בעל יכולות מתקדמות הרבה יותר מאשר חלקים אחרים במכשיר.
הרחבה: הכלים המתאימים למשימה
ברגע שתהיה לנו אמינות וביצועים ניתנים להרחבה, אנחנו מוכנים עכשיו להתבסס על מגוון כלים שיעזרו למפתחים להרחיב את החלקים המובנים של HTML, CSS ולוח הציור, ובדרכים שלא מתפשרות על הביצועים והאמינות המושקעים האלה.
זה כולל ממשקי API מובנים וגלויים ב-JavaScript לתרחישים מתקדמים לדוגמה של עיצוב רספונסיבי, רינדור מתקדם, החלקה ותגובתיות, ורינדור בשרשור.
ממשקי ה-API הבאים לאינטרנט, שהוטמעו על ידי Chromium, התאפשרו על ידי RenderingNG ובעבר נחשבו כלא מעשיים.
כולם פותחו עם מפרטים פתוחים ושיתוף פעולה עם שותפי אינטרנט פתוחים - מהנדסים של דפדפנים אחרים, מומחים ומפתחי אינטרנט. בפוסטים הבאים בבלוג, נתעמק בכל אחד מהם ונסביר איך RenderingNG מאפשר אותם.
- content-visibility: מאפשרת לאתרים להימנע בקלות מעיבוד של תוכן שלא מופיע במסך, ומעיבוד של תוכן במטמון לצפיות של אפליקציה בדף יחיד שלא מוצגות כרגע.
- OffscreenCanvas: עיבוד של קנבס (גם ממשק ה-API של בד ציור דו-ממדי וגם WebGL) יכול לפעול בשרשור נפרד, כדי לקבל ביצועים מצוינים. הפרויקט הזה הוא גם ציון דרך חשוב נוסף באינטרנט – הוא ה-API הראשון באינטרנט שמאפשר ל-JavaScript (או ל-WebAssembly!) לעבד מסמך יחיד של דף אינטרנט מכמה שרשורים.
- שאילתות של קונטיינרים: מאפשרות לרכיב יחיד לפרוס את עצמו באופן רספונסיבי, ולבטל את החסימה של מגוון שלם של רכיבי פלאגין-הפעלה (כרגע בהטמעה ניסיונית).
- בידוד המקור: מאפשר לאתרים להביע הסכמה לבידוד רב יותר של ביצועים בין מסגרות iframe.
- עיבודי צבע מחוץ לשרשור הראשי: מאפשרים למפתחים להרחיב את תהליך הצביעה של רכיבים באמצעות קוד שרץ ב-thread של הקומפוזיציה.
בנוסף לממשקי API מפורשים לאינטרנט, RenderingNG מאפשר לנו לשלוח כמה "תכונות אוטומטיות" משמעותיות מאוד שמועילות לכל האתרים:
- Site Isolation: בידוד של מסגרות iframe ממקורות שונים לתהליכי מעבד (CPU) שונים, כדי לשפר את האבטחה ואת הבידוד של הביצועים.
- ב-Vulkan, ב-D3D12 וב-Metal, ממשקי API ברמה נמוכה יותר שמשתמשים במעבדי GPU בצורה יעילה יותר מאשר OpenGL.
- אנימציות מורכבות יותר: SVG, צבע רקע.
תכונות נוספות שהחסימה שלהן בוטלה על ידי RenderingNG משמחת אותנו מאוד כוללות את:
- גלילה באנימציות שמקושרות.
- DOM מוסתר, אבל עדיין ניתן לחיפוש ונגיש.
- מעברים משותפים של רכיבים.
- פריסה בהתאמה אישית.
- הרכבה של מחוץ ל-thread הראשי; הפרדת שרשורים והרכבה.
פרויקטים מרכזיים שמהם מורכב RenderingNG
בהמשך מופיעה רשימה של הפרויקטים העיקריים ב-RenderingNG.
CompositeAfterPaint
שילוב של CompositeAfterPaint מתבצע על סמך סגנון, פריסה וצבע, וכך מאפשר אמינות משופרת וביצועים צפויים, תפוקה מוגברת ושימוש בפחות זיכרון בלי לפגוע בביצועים.
שנה | ההתקדמות |
---|---|
2015 | רשימות לתצוגה של משלוחים. |
2017 | שליחת ביטול תוקף חדש. |
2018 | עצי אונייה – חלק 1. |
2019 | עצי אונייה – חלק 2. |
2021 | משלוח הפרויקט הושלם. |
LayoutNG
שכתוב של כל האלגוריתמים של הפריסה, לשיפור המהימנות ולביצועים צפויים יותר.
מידע נוסף על LayoutNG.
שנה | ההתקדמות |
---|---|
2019 | תהליך של חסימת משלוח. |
2020 | שליחה גמישה, עריכה. |
2021 | לשלוח את כל השאר. |
BlinkNG
שילבנו מחדש את הרכיבים של מנוע העיבוד של Blink והעברנו אותם לשלבים מופרדים בצורה ברורה בצינור עיבוד הנתונים. כך אפשר לשמור טוב יותר במטמון, לקבל אמינות גבוהה יותר ולהשתמש בתכונות של גיוס מחדש או רינדור מאוחר, כמו הרשאות חשיפה לתוכן ושאילתות בקונטיינרים.
האצת GPU בכל מקום
האצת GPU מספקת מהירות אדירה לרוב התוכן, כי ניתן לעבד כל פיקסל במקביל. זוהי גם שיטה יעילה לשיפור הביצועים במכשירים פשוטים, שבדרך כלל עדיין כוללים GPU.
שנה | ההתקדמות |
---|---|
2014 | תמיכה בלוח הציור. נשלח בתוכן של הבעת הסכמה ב-Android. |
2016 | נשלח ב-Mac. |
2017 | יותר מ-60% מהצפיות בדפים ב-Android משמשות ב-GPU. |
2018 | אפשר להשתמש בהם ב-Windows, ב-ChromeOS וב-Android Go. |
2019 | יצירת רשת נקודות של GPU בשרשור. |
2020 | שליחת תוכן Android שנותר. |
גלילה בשרשור, אנימציות ופענוח קוד
מאמץ ארוך טווח להעברת כל האנימציות, האנימציות ופענוח התמונות מהשרשור הראשי. הוא מתמשך.
שנה | ההתקדמות |
---|---|
2011 | תמיכה ראשונית בגלילה משרשורים ובאנימציה. |
2015 | דחיסת שכבות. |
2016 | גלילת גלישה אוניברסלית. |
2017 | פענוח התמונה ב-thread של קומפוזיציה. |
2018 | אנימציות של תמונות בשרשור של המחבר. |
2020 | תמיד מורכב במצב קבוע. |
2021 | אחוזי טרנספורמציה של אנימציות, אנימציות SVG. |
Viz
תהליך ציור מרוכז של רסטר ו-Chromium שמגדיל את התפוקה, מבצע אופטימיזציה של הזיכרון ומאפשר שימוש אופטימלי ביכולות החומרה. יש לו יתרונות אחרים פחות גלויים למפתחי אתרים אבל הם גלויים מאוד למשתמשים, כמו ביטול החסימה של 'בידוד של אתר' והפרדת צינור עיבוד הנתונים מרינדור מרינדור ממשק המשתמש של הדפדפן.
שנה | ההתקדמות |
---|---|
2018 | OOP-R נשלח ל-Android, ל-Mac ול-Windows. |
2019 | OOP-D נשלח. OOP-R נשלח בכל מקום (למעט קנבס). SkiaRenderer נשלח מ-Linux. |
2020 | SkiaRenderer נשלח ל-Windows ול-Android. Vulkan נשלחת ל-Android. |
2021 | SkiaRenderer נשלח ב-Mac (ו-ChromeOS בקרוב). |
הגדרות של מונחים בתרשים שלמעלה:
- OOP-D
- מחבר תצוגה מחוץ לתהליך. יצירת הרכבה של תצוגה היא אותו סוג של פעילות כמו מחבר של מערכת הפעלה. 'לא בתהליך' פירושו לעשות זאת בתהליך Viz במקום בתהליך העיבוד של דף האינטרנט או בתהליך ממשק המשתמש של הדפדפן.
- OOP-R
- רסטר לא בתהליך. Raster ממירה רשימות תצוגה לפיקסלים. 'לא בתהליך' פירושו לעשות זאת בתהליך Viz במקום בתהליך העיבוד של דף האינטרנט.
- SkiaRenderer
- הטמעה חדשה של קומפוזבילי פרסום לתצוגה שיכולה לתמוך בביצוע במגוון ממשקי API שונים של GPU כמו Vulkan, D3D12 או Metal.
עיבוד מהיר של אזור העריכה והרינדור של אזור העריכה
זה הפרויקט שמאפשר את OffscreenCanvas.
שנה | ההתקדמות |
---|---|
2018 | Ship OffscreenCanvas. |
2019 | שליחת ImageBitmapRenderingContext. |
2021 | משלוח OOP-R. |
VideoNG
VideoNG הוא פתרון ארוך טווח לספק הפעלה יעילה, אמינה ואיכותית באינטרנט.
שנה | ההתקדמות |
---|---|
2014 | השקנו מסגרת רינדור מבוססת Mojo. |
2015 | Project Butter ושכבות-על של סרטונים נשלחו לעיבוד חלק יותר של הסרטון. |
2016 | צינורות עיבוד נתונים מאוחדים לפענוח ולעיבוד של Android ומחשבים, שנשלחו. |
2017 | HDR ורינדור וידאו עם תיקון צבע שנשלחו. |
2018 | צינור עיבוד נתונים של Mojo לפענוח סרטון. |
2019 | צינור עיבוד וידאו לרינדור וידאו שמבוסס על פלטפורמה שנשלחת. |
2021 | תמיכה ברינדור של תוכן מוגן באיכות 4K ב-ChromeOS. |
הגדרות של מונחים בתרשים שלמעלה:
- מוג'ו
- דור הבא של מערכת משנה של IPC ל-Chromium.
- פלטפורמה
- קונספט שהוא חלק מהתכנון של פרויקט Viz.
איורים של אונה קראבטס.