איך למדוד ביצועים של גרפיקה בדפדפן

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

דוגמה לזמן! זהו קטע קוד קצר עם פונקציית tick לבדיקת ביצועים. הפונקציה tick קוראת לפונקציה draw עם עומס גרפי הולך וגדל עד שהזמן הנדרש לציור עולה באופן עקבי על 33 אלפיות השנייה.

var t, previousTime;
var drawLoad = 1;
var slowCount = 0;
var maxSlow = 10;
// Note, you might need to polyfill performance.now and requestAnimationFrame
t = previousTime = performance.now();
var tick = function() {
    var maximumFrameTime = 1000/30; // 30 FPS
    t = performance.now();
    var elapsed = t - previousTime;
    previousTime = t;
    if (elapsed < maximumFrameTime || slowCount < maxSlow) {
        if (elapsed < maximumFrameTime) {
            drawLoad+=10;
        } else {
            slowCount++;
        }
        draw(drawLoad);
        requestAnimationFrame(tick);
    } else {
        // found maximum sustainable load at 30 FPS
        document.getElementById('res').innerHTML = ("could draw "+(drawLoad)+" in " +
            maximumFrameTime + " ms");
    }
};
requestAnimationFrame(tick);

​ הדוגמה הפעילה ב-jsFiddle

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

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

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

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

שימוש ב-setTimeout למדידת ביצועי הגרפיקה היא רעיון גרוע נוסף. מרווח הזמן של setTimeout מוגבל ל-4 אלפיות שנייה בדפדפנים, כך שהמקסימום שאפשר לקבל ממנו הוא 250FPS. בעבר, למוצרים שונים של דפדפנים היו מרווחי זמן מינימלי שונים, כך שיכול להיות שהיה לכם מדד ביצועים טריוויאלי מאוד של ציור שמוצג בו שדפדפן א' פועל במהירות של 250FPS (מרווח זמן מינימלי של 4ms) ודפדפן ב' פועל במהירות של 100FPS (מרווח זמן מינימלי של 10ms). ברור שאפשרות א' מהירה יותר! לא! יכול להיות ש-B הפעיל את קוד התצוגה מהר יותר מ-A, נניח של-A נדרשו 3 אלפיות שנייה ול-B נדרשה 1 אלפית שנייה. זה לא משפיע על קצב הפריימים, כי זמן התצוגה קצר יותר מהמרווח המינימלי של setTimeout. אם הדפדפן מבצע עיבוד נתונים באופן אסינכררוני, אין לכם מה לעשות. אל תשתמשו ב-setTimeout אלא אם אתם יודעים מה אתם עושים.

איך עושים את זה במקרה כזה

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

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

כדי ללמוד איך לכתוב קוד גרפי לאינטרנט עם ביצועים גבוהים, כדאי לצפות בהרצאה של Nat Duca ו-Tom Wiltzius מצוות ה-GPU של Chrome ב-Google I/O 2012.