قياس أداء رسومات المتصفّح باختصار: ارسم أكبر قدر ممكن من الرسومات مع الحفاظ على سلاسة عدد اللقطات في الثانية. وعندما ينخفض عدد اللقطات في الثانية، سيصبح بإمكانك معرفة مقدار ما يمكنك رسمه في كل إطار. نهاية المشاركة. لا؟ حسنًا، سأشرح المزيد من التفاصيل.
مثال على وقت في ما يلي مقتطف رمز صغير يتضمّن دالة 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
يمكنك الاطّلاع على الطريقة التي يواصل بها مقياس الأداء رسمه أكثر فأكثر إلى أن يصل إلى النقطة التي ينخفض فيها. هذه طريقة لطيفة وبسيطة لمعرفة مقدار ما يمكنك رسمه بمعدل عرض إطارات سلس. يمكنك أيضًا إضافة دالة الرسم الخاصة بك إلى المثال وإجراء بعض مقاييس الأداء المخصصة، مهلاً!
المحاذير والمخاطر الشائعة عند قياس رسومات المتصفِّح
إذن، إذا كان المثال أعلاه هو طريقة لطيفة لفعله، فما هي الطرق غير اللطيفة؟ الطرق التي تؤدي إلى قياس الأداء لأشياء غير مرتبطة ببعضها البعض أو التي تمنحك مقاييس أداء غريبة لا يبدو لها أي علاقة بسرعة تشغيل تطبيقك. سعدتُ بسؤالك. إليك أكثرهما شيوعًا رأيتهما على الويب.
قياس الحد الأقصى لعدد اللقطات في الثانية: ارسم كل إطار قليلاً وقم بقياس عدد اللقطات في الثانية. ولا يعمل بشكل جيد عند قياس أداء الرسومات على Chrome بسبب مزامنة تنفيذ الرسومات الأساسية مع معدّل تحديث الشاشة (وبذلك تحصل على 60 تحديثًا للشاشة في الثانية كحد أقصى). لن يكون قياس سرعة طلب الرسم مفيدًا للغاية، سواءً كان نظام الرسم في Chrome يضع أوامر الرسم في المخزن المؤقت للأوامر الذي يتم تنفيذه في عملية تحديث الشاشة التالية.
من الأفكار السيئة الأخرى استخدام setTimeout لقياس أداء الرسومات. تم تقييد الفاصل الزمني لمهلة setTimeout إلى 4 ملي ثانية في المتصفِّحات، وبالتالي فإنّ أقصى ما يمكنك الاستفادة منه هو 250 لقطة في الثانية. سابقًا، كان للمتصفّحات الحد الأدنى لفواصل زمنية مختلفة، لذا قد يكون لديك مقياس أداء رسم تافه معطّل للغاية يُظهر أنّ المتصفح A يعمل بمعدل 250 لقطة في الثانية (فاصل زمني 4 ملي ثانية) والمتصفح B يعمل بسرعة 100 لقطة في الثانية (فاصل زمني 10 ملي ثانية). من الواضح أن حرف A أسرع! لا! قد يكون السبب هو أن B شغّل رمز الرسم أسرع من A، لنفترض أن A استغرقت 3 ملي ثانية وB استغرقت 1 ملي ثانية. ولا يؤثر ذلك في عدد اللقطات في الثانية، لأن وقت الرسم أقل من الحد الأدنى للفاصل setTimeout. وإذا كان يتم عرض المتصفّح بشكل غير متزامن، سيتم إيقاف جميع الرهانات. ولا تستخدم setTimeout إلا إذا كنت تعرف ما تفعله.
كيف يتم ذلك إذًا
ومن أفضل الطرق لقياس الأداء استخدام حمل رسم واقعي وضربه حتى يبدأ معدّل عرض الإطارات في التغيُّر. على سبيل المثال، إذا كنت تكتب لعبة من أعلى إلى أسفل باستخدام خريطة صور متجانبة، جرِّب رسم خريطة مربّعات في كل إطار ومعرفة ما إذا كانت تعمل بمعدّل 60 لقطة في الثانية. إذا كانت الإجابة "نعم"، عليك زيادة الحمل (ارسم خريطة مربّعات مرتين في كل إطار، مع ترك مساحة واضحة في المنتصف). واصِل زيادة عدد اللقطات في الثانية إلى أن ينخفض عدد اللقطات في الثانية إلى مستوى ثابت جديد. أنت تعرف الآن عدد طبقات خريطة المربعات التي يمكنك رسمها لكل إطار.
تختلف احتياجات تطبيقات الرسومات المختلفة، لذا يجب عليك كتابة معاييرك مع وضع ذلك في الاعتبار. قياس ميزات الرسومات التي تستخدمها في تطبيقك. وعندما تجد سيناريو بطيئًا، حاوِل تقليله إلى أصغر جزء من الرمز يعيد إنتاجه (وقدِّم تقرير خطأ على new.crbug.com إذا كان من المفترض أن يكون أسرع).
لمعرفة كيفية كتابة رموز رسومات على الويب عالية الأداء، يمكنك الاطلاع على محادثة مؤتمر Google I/O 2012 التي أجرتها كل من نات دوكا وتوم ويلتزيوس من فريق وحدة معالجة الرسومات في Chrome.