ब्राउज़र के ग्राफ़िक को बेंचमार्क करने के बारे में खास जानकारी: फ़्रेम रेट को स्मूद बनाए रखते हुए, ज़्यादा से ज़्यादा ड्रॉ करें. फ़्रेम रेट गिरने के बाद, आपको पता चल जाता है कि हर फ़्रेम में कितनी जानकारी डाली जा सकती है. पोस्ट खत्म हो गई. नहीं? ठीक है, मैं आपको ज़्यादा जानकारी दूंगा.
समय का उदाहरण! यहां एक छोटा कोड स्निपेट दिया गया है, जिसमें बेंचमार्किंग 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 FPS मिल सकता है. पहले, ब्राउज़र के लिए अलग-अलग कम से कम इंटरवल तय किए जाते थे. इसलिए, हो सकता है कि आपके पास बहुत खराब ट्रिवल ड्रॉ बेंचमार्क हो, जिसमें ब्राउज़र A को 250 FPS (कम से कम 4 मिलीसेकंड का इंटरवल) और ब्राउज़र B को 100 FPS (कम से कम 10 मिलीसेकंड का इंटरवल) पर चलता हुआ दिखाया गया हो. साफ़ तौर पर, A तेज़ है! नहीं! ऐसा हो सकता है कि B ने ड्रॉ कोड को A से ज़्यादा तेज़ी से चलाया हो. मान लें कि A को 3 मि॰से॰ और B को 1 मि॰से॰ लगे. इससे एफ़पीएस पर कोई असर नहीं पड़ता, क्योंकि ड्रॉ का समय, setTimeout फ़ंक्शन के लिए तय किए गए कम से कम इंटरवल से कम है. अगर ब्राउज़र असिंक्रोनस तरीके से रेंडर करता है, तो कोई भी अनुमान नहीं लगाया जा सकता. जब तक आपको यह नहीं पता कि क्या किया जा रहा है, तब तक setTimeout का इस्तेमाल न करें.
ऐसा कैसे करें
बेंचमार्क करने का बेहतर तरीका यह है कि रीयलिस्टिक ड्रॉइंग लोड का इस्तेमाल करें और उसे तब तक बढ़ाएं, जब तक फ़्रेम रेट में गिरावट न आ जाए. उदाहरण के लिए, अगर टाइलमैप टेरेन के साथ टॉप-डाउन गेम लिखा जा रहा है, तो हर फ़्रेम में टाइलमैप को ड्रॉ करके देखें कि वह 60 FPS पर चलता है या नहीं. अगर हां, तो लोड बढ़ाएं (हर फ़्रेम में टाइलमैप को दो बार ड्रॉ करें, बीच में क्लियर करें). तब तक एफ़पीएस बढ़ाते रहें, जब तक कि यह एक नए स्थिर लेवल पर न आ जाए. अब आपको पता है कि हर फ़्रेम में टाइलमैप की कितनी लेयर बनाई जा सकती हैं.
अलग-अलग ग्राफ़िक्स ऐप्लिकेशन की ज़रूरतें अलग-अलग होती हैं. इसलिए, आपको अपने मानदंडों को इस बात को ध्यान में रखकर लिखना चाहिए. अपने ऐप्लिकेशन में इस्तेमाल की जा रही ग्राफ़िक सुविधाओं को मेज़र करें. अगर आपको कोई धीमा सीनरी मिलती है, तो उसे उस छोटे से कोड तक कम करने की कोशिश करें जो उसे दोहराता है. अगर आपको लगता है कि इसे तेज़ किया जाना चाहिए, तो new.crbug.com पर गड़बड़ी की शिकायत दर्ज करें.
बेहतर परफ़ॉर्मेंस वाला वेब ग्राफ़िक कोड लिखने का तरीका जानने के लिए, Chrome GPU टीम के नैट ड्यूका और टॉम विल्टज़ियस का Google I/O 2012 टॉक देखें.