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