ניהול עיבוד

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

מתי כדאי להקפיד

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

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

איך זה עובד

1. הבאים בתור באופן אוטומטי. בכל פעם שמשנים בלוק, Blockly 'שומרת בתור' עיבוד של הבלוק הזה. כמה דוגמאות לשינויים שמובילים לרינדור הן:

   • הגדרת ערך של שדה
   • הוספה או הסרה של קלט
   • קישור או ניתוק של בלוק צאצא

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

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

4. ביצוע עיבוד מחדש של הקבוצה (כעץ). כשמתבצעת קריאה ל-callback של requestAnimationFrame, מערכת ניהול הרינדור מרינדרת כל בלוק בקבוצה, החל מבלוק עלה ועד לבלוק ברמה הבסיסית. כך אפשר לוודא שבלוקים של צאצאים מידע מדויק על הגודל לפני עיבוד בלוקים ההורה שלהם כך בלוקים של הורה יכולים למתח סביב ילדיהם.

הערה: שינויים שמשפיעים רק על הצבע של הבלוק ולא על הצורה שלו (למשל, השבתת החסימה) לא להוסיף רינדור בתור. הצבעים עודכנו באמצעות BlockSvg.prototype.applyColour בנפרד.

למה זה עובד?

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

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

איך להשתמש בעמודה

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

עיבודים בתור

אם מוסיפים ל-Blockly method חדש שצריך לעדכן את הצורה של בלוק, צריך לקרוא ל-BlockSvg.prototype.queueRender כדי להוסיף את הבלוק לרשימת ה-render.

יש להמתין לסיום העיבודים

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

import * as renderManagement from './renderManagement.js';

function async myNewMethod() {
  block.somethingThatModifiesTheShape();
  // Await the promise.
  await renderManagement.finishQueuedRenders();
  myThingThatReliesOnPositioningInfo();
}

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

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

import * as renderManagement from './renderManagement.js';

function async myNewMethod() {
  block.somethingThatModifiesTheShape();
  // Trigger an immediate render.
  renderManagement.triggerQueuedRenders();
  myThingThatReliesOnPositioningInfo();
}

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

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