फ़्रेम पेसिंग लाइब्रेरी Android गेम डेवलपमेंट किट का हिस्सा.

Android फ़्रेम पेसिंग लाइब्रेरी को स्वैपी के नाम से भी जाना जाता है. यह एजीडीके लाइब्रेरी का हिस्सा है. इससे OpenGL और Vulkan गेम को बेहतर रेंडरिंग की सुविधा मिलती है. Android पर फ़्रेम पेसिंग सही होनी चाहिए. इस दस्तावेज़ में फ़्रेम पेसिंग के बारे में बताया गया है. उन स्थितियों के बारे में बताया गया हो जिनमें फ़्रेम पेसिंग की ज़रूरत होती है. साथ ही, दिखाता है कि लाइब्रेरी इन स्थितियों में मदद कर सकता है. अगर आपको सीधे तौर पर फ़्रेम पेसिंग लागू करनी है, तो तो अगला चरण देखें.

बैकग्राउंड

फ़्रेम पेसिंग का मतलब है कि किसी गेम के लॉजिक और रेंडरिंग लूप को ओएस के डिसप्ले सबसिस्टम और उसका डिसप्ले हार्डवेयर. Android डिसप्ले सबसिस्टम को विज़ुअल आर्टफ़ैक्ट (जिसे टियरिंग कहा जाता है) से बचाने के लिए डिज़ाइन किया गया है ऐसा तब हो सकता है, जब डिसप्ले हार्डवेयर किसी नए फ़्रेम के पार्ट-वे पर स्विच हो जाता है अपडेट किया जा सकता है. इन आर्टफ़ैक्ट से बचने के लिए, डिसप्ले सबसिस्टम ये काम करता है: फ़ॉलो किया जा रहा है:

  • पिछले फ़्रेम को अंदरूनी रूप से बफ़र करता है
  • देरी से सबमिट किए गए फ़्रेम का पता लगाता है
  • देर से फ़्रेम का पता चलने पर, पिछले फ़्रेम का डिसप्ले दोहराया जाएगा

गेम से जानकारी मिलती है SurfaceFlinger, डिसप्ले सबसिस्टम के अंदर मौजूद कंपोज़िटर, जिसने सभी ड्रॉ सबमिट कर दिए हैं फ़्रेम के लिए ज़रूरी कॉल (eglSwapBuffers या vkQueuePresentKHR पर कॉल करके). SurfaceFlinger, डिसप्ले हार्डवेयर के लिए फ़्रेम की उपलब्धता के बारे में बताता है. इसके लिए, लैच. इसके बाद, डिसप्ले हार्डवेयर दिए गए फ़्रेम को दिखाता है. डिसप्ले हार्डवेयर स्थिर दर पर टिक होता है, उदाहरण के लिए 60 हर्ट्ज़, और अगर कोई नया फ़्रेम नहीं है, हार्डवेयर को इसकी ज़रूरत होती है, तो हार्डवेयर पिछले फ़्रेम को फिर से दिखाता है.

जब गेम रेंडर लूप, रेंडर होने के दौरान स्थानीय डिसप्ले हार्डवेयर से अलग दर है. अगर 30 एफ़पीएस (फ़्रेम प्रति सेकंड) पर चल रहा गेम किसी ऐसे डिवाइस पर रेंडर करने की कोशिश करता है जो मूल रूप से 60 FPS (फ़्रेम प्रति सेकंड) पर काम करता है, यानी कि गेम लूप को पता नहीं चलता कि अतिरिक्त 16 के साथ स्क्रीन पर एक डुप्लीकेट फ़्रेम बचा रहता है मिलीसेकंड. इस डिसकनेक्ट से आम तौर पर, फ़्रेम में काफ़ी अंतर होता है समय, जैसे कि: 49 मिलीसेकंड, 16 मिलीसेकंड, 33 मिलीसेकंड. ज़रूरत से ज़्यादा जटिल सीन इस समस्या को और बढ़ा देते हैं, क्योंकि उनसे फ़्रेम छूट जाते हैं होता है.

कम फ़ायदे

गेम में, फ़्रेम पेसिंग के लिए नीचे दिए गए तरीकों का इस्तेमाल किया जा रहा है इस वजह से, आम तौर पर फ़्रेम टाइम में अंतर हो सकता है और इनपुट में लगने वाला समय बढ़ सकता है.

रेंडरिंग एपीआई की अनुमति के हिसाब से, फ़्रेम जल्द से जल्द सबमिट करें

यह तरीका, गेम को अलग-अलग SurfaceFlinger गतिविधि के साथ जोड़ता है और इंतज़ार का समय. डिसप्ले पाइपलाइन में फ़्रेम की एक सूची होती है, यह गेम आम तौर पर साइज़ 2 की जगह लेता है. ऐसा तब होता है, जब गेम में फ़्रेम दिखाने की कोशिश की जाती है. तेज़ी से काम करता है. सूची में जगह न होने से, गेम लूप (या कम से कम रेंडरिंग थ्रेड) को OpenGL या Vulkan कॉल से ब्लॉक किया गया. गेम तो डिस्प्ले हार्डवेयर के लिए फ़्रेम दिखाने के लिए प्रतीक्षा करनी पड़ती है और यह बैक-प्रेशर दोनों कॉम्पोनेंट को सिंक करता है. इस स्थिति को बफ़र स्टफ़िंग कहा जाता है या सूची में कुछ जोड़ना. रेंडर करने की प्रोसेस को पता नहीं होता कि क्या हो रहा है, इसलिए फ़्रेमरेट असंगति बदतर हो जाती है. अगर गेम के सैंपल, फ़्रेम से पहले इनपुट किए जाते हैं, इसलिए इनपुट के लिए इंतज़ार का समय और खराब हो जाता है.

Android कोरियोग्राफ़र का इस्तेमाल करना

गेम सिंक करने के लिए, Android कोरियोग्राफ़र का भी इस्तेमाल करते हैं. यह कॉम्पोनेंट, यह एपीआई 16 से Java में और एपीआई 24 से C++ में उपलब्ध है. साथ ही, सामान्य टिक यहां डिलीवर करता है और डिसप्ले सबसिस्टम की फ़्रीक्वेंसी एक जैसी है. इस तरह की बारीकियां अब भी जब इस टिक को असल हार्डवेयर VSYNC के मुताबिक डिलीवर किया जाता है, और ये डिवाइस के हिसाब से ऑफ़सेट अलग-अलग होते हैं. लंबे फ़्रेम के लिए भी बफ़र स्टफ़िंग की सुविधा काम कर सकती है.

फ़्रेम पेसिंग लाइब्रेरी के फ़ायदे

फ़्रेम पेसिंग लाइब्रेरी, सिंक करने के लिए Android कोरियोग्राफ़र का इस्तेमाल करती है और टिक डिलीवरी में आने वाले उतार-चढ़ाव को हैंडल करता है. यह प्रज़ेंटेशन का इस्तेमाल करता है टाइमस्टैंप से यह पक्का किया जा सकता है कि फ़्रेम सही समय पर दिखें और फ़ेंस सिंक करें बफ़र स्टफ़िंग से बचा जा सकता है. लाइब्रेरी, एनडीके कोरियोग्राफ़र, अगर यह उपलब्ध है और जावा कोरियोग्राफ़र के तौर पर वापस आ जाते हैं, अगर नहीं.

अगर रीफ़्रेश दर डिवाइस पर काम करती है, तो लाइब्रेरी एक से ज़्यादा रीफ़्रेश दर को हैंडल करती है, इससे, गेम को फ़्रेम के साथ प्रज़ेंट करने में ज़्यादा आसानी होती है. उदाहरण के लिए, एक ऐसा गेम जो 60 हर्ट्ज़ और 90 हर्ट्ज़ की रीफ़्रेश दर के साथ काम करता है. यह एक ऐसा गेम है जो हर सेकंड में 60 फ़्रेम जनरेट होने पर, यह 30 FPS के बजाय 45 FPS (फ़्रेम प्रति सेकंड) तक पहुंच सकता है शानदार. इस लाइब्रेरी से, गेम के फ़्रेम रेट और अपने-आप अडजस्ट होने वाले फ़्रेम रेट का पता चलता है प्रज़ेंटेशन का समय भी तय किया जा सकता है. फ़्रेम पेसिंग लाइब्रेरी से बैटरी को बेहतर बनाने में भी मदद मिलती है लाइफ़ है क्योंकि यह गै़र-ज़रूरी डिसप्ले अपडेट से बचाता है. उदाहरण के लिए, अगर कोई गेम 60 FPS पर रेंडर हो रहा है, लेकिन डिसप्ले 120 हर्ट्ज़ पर अपडेट हो रहा है. हर फ़्रेम के लिए दो बार अपडेट किया जाता है. फ़्रेम पेसिंग लाइब्रेरी, सेटिंग का इस्तेमाल करके इससे बच सकती है टारगेट के सबसे करीब मौजूद डिवाइस पर काम करने वाली वैल्यू की रीफ़्रेश दर फ़्रेम रेट.

यह कैसे काम करता है

यहां दिए गए सेक्शन दिखाते हैं कि फ़्रेम पेसिंग लाइब्रेरी, ताकि सही फ़्रेम पेसिंग पाने के लिए, छोटे गेम फ़्रेम बनाए जा सकें.

फ़्रेम पेसिंग को 30 हर्ट्ज़ पर सही करें

किसी 60 हर्ट्ज़ वाले डिवाइस पर 30 हर्ट्ज़ पर रेंडरिंग करते समय, Android के लिए सबसे सही स्थिति यह है पहली इमेज में दिखाया गया है. मौजूद होने पर SurfaceFlinger, नए ग्राफ़िक बफ़र को चालू करती है (NB in इस डायग्राम में दिखाया गया है कि "कोई बफ़र नहीं" है मौजूद है और पिछला वाला दोहराया गया है).

60 हर्ट्ज़ वाले डिवाइस पर 30 हर्ट्ज़ पर फ़्रेम पेसिंग सही होती है

पहला डायग्राम. 60 हर्ट्ज़ वाले डिवाइस पर 30 हर्ट्ज़ पर फ़्रेम पेसिंग सही होती है

छोटे-छोटे फ़्रेम फ़्रेम में आने पर उपयोगकर्ता रुक जाते हैं

ज़्यादातर आधुनिक डिवाइसों में, गेम इंजन के लिए प्लैटफ़ॉर्म कोरियोग्राफ़र का इस्तेमाल किया जाता है टिक डिलीवर करना. हालांकि, अब भी यह इमेज, दूसरी इमेज में दिखाई गई है. छोटे फ़्रेम के बाद लंबे फ़्रेम को प्लेयर देखता है.

छोटे गेम फ़्रेम

दूसरा डायग्राम. छोटे गेम फ़्रेम C की वजह से फ़्रेम B में सिर्फ़ एक फ़्रेम दिखता है, इसके बाद कई C फ़्रेम शामिल हों

फ़्रेम पेसिंग लाइब्रेरी, प्रज़ेंटेशन के टाइमस्टैंप का इस्तेमाल करके इस समस्या को हल करती है. कॉन्टेंट बनाने लाइब्रेरी, प्रज़ेंटेशन टाइमस्टैंप एक्सटेंशन का इस्तेमाल करती है EGL_ANDROID_presentation_time और VK_GOOGLE_display_timing ताकि फ़्रेम जल्दी दिखाई न दें, जैसा कि तीसरी इमेज में दिखाया गया है.

प्रज़ेंटेशन के टाइमस्टैंप

तीसरी इमेज. बेहतर डिसप्ले के लिए, गेम फ़्रेम B को दो बार दिखाया गया

लंबे फ़्रेम बनाने पर वीडियो रुक-रुककर चलते हैं और वीडियो स्ट्रीम होने में लगने वाला समय बढ़ जाता है

जब डिसप्ले वर्कलोड में ऐप्लिकेशन के वर्कलोड से ज़्यादा समय लगता है, तो एक्स्ट्रा फ़्रेम सूची में जोड़े जाते हैं. इससे एक बार फिर से हकलाने की समस्या बढ़ जाती है और बफ़र स्टफ़िंग की वजह से, इंतज़ार का समय ज़्यादा हो जाता है (इमेज 4 देखें). कॉन्टेंट बनाने लाइब्रेरी, स्टट्रिंग और लेटेंसी के अतिरिक्त फ़्रेम को हटा देती है.

गेम के लंबे फ़्रेम

चौथी इमेज. लंबी फ़्रेम B, दो फ़्रेम के लिए गलत पेसिंग दिखाती है—A और B

लाइब्रेरी इस समस्या को हल करने के लिए, सिंक फ़ेंस का इस्तेमाल करती है (EGL_KHR_fence_sync और VkFence) इंजेक्ट करने के लिए, ऐप्लिकेशन में इंतज़ार किया जाता है. इससे डिसप्ले पाइपलाइन को काफ़ी ज़्यादा होता है. फ़्रेम A स्टिल इमेज दिखाता है में अतिरिक्त फ़्रेम है, लेकिन फ़्रेम B अब सही तरीके से दिखता है, जैसा कि पांचवीं इमेज में दिखाया गया है.

ऐप्लिकेशन लेयर में इंतज़ार का समय जोड़ा गया

पांचवी इमेज. फ़्रेम C और D प्रजेंट करने के लिए इंतज़ार करते हैं

Gemini के साथ काम करने वाले ऑपरेटिंग मोड

फ़्रेम पेसिंग लाइब्रेरी को, इन तीन में से किसी एक में इस्तेमाल करने के लिए कॉन्फ़िगर किया जा सकता है इनमें से कोई मोड चुनें:

  • ऑटो मोड बंद है + पाइपलाइन
  • ऑटो मोड चालू है और पाइपलाइन
  • ऑटो मोड चालू है + ऑटो पाइपलाइन मोड (पाइपलाइन/नॉन-पाइपलाइन)

इसमें ऑटो-मोड और पाइपलाइन मोड के साथ एक्सपेरिमेंट किया जा सकता है. हालांकि, शुरुआत करने के लिए आपको इन्हें बंद कर दें और Swippy शुरू करने के बाद निम्न को शामिल कर लें:

  swappyAutoSwapInterval(false);
  swappyAutoPipelineMode(false);
  swappyEnableStats(false);
  swappySwapIntervalNS(1000000000L/yourPreferredFrameRateInHz);

पाइपलाइन मोड

इंजन के वर्कलोड को मैनेज करने के लिए, लाइब्रेरी में आम तौर पर पाइपलाइनिंग मॉडल का इस्तेमाल किया जाता है इसकी मदद से, सीपीयू और जीपीयू के वर्कलोड को VSYNC की सीमाओं से अलग किया जा सकता है.

पाइपलाइन मोड

छठी इमेज. पाइपलाइन मोड

नॉन-पाइपलाइन मोड

आम तौर पर, इस तरीके का इस्तेमाल करने पर, इनपुट-स्क्रीन कम मिलती है और उसका अनुमान लगाया जाता है इंतज़ार का समय. गेम में फ़्रेम टाइम बहुत कम होने पर, सीपीयू और जीपीयू, दोनों का इस्तेमाल किया जाता है वर्कलोड एक ही स्वैप इंटरवल में फ़िट हो सकते हैं. इस मामले में, एक गैर-पाइपलाइनेड इस तरीके का इस्तेमाल करने पर, इनपुट-स्क्रीन पर लगने वाला समय कम हो जाएगा.

नॉन-पाइपलाइन मोड

सातवीं इमेज. नॉन-पाइपलाइन मोड

ऑटो मोड

ज़्यादातर गेम में स्वैप करने का इंटरवल चुनने का तरीका नहीं पता होता. यह इंटरवल जो हर फ़्रेम के लिए दिखाया जाता है (उदाहरण के लिए, 30 हर्ट्ज़ के लिए 33.3 मि॰से॰). कुछ डिवाइसों पर, किसी गेम को 60 FPS (फ़्रेम प्रति सेकंड) पर रेंडर किया जा सकता है, जबकि दूसरे पर रेंडर होने की उसकी स्पीड कम हो सकती है वैल्यू. ऑटो मोड, सीपीयू और जीपीयू समय का आकलन करता है, ताकि ये काम किए जा सकें:

  • स्वैप इंटरवल अपने-आप चुनें: ऐसे गेम जो कुछ में 30 हर्ट्ज़ देते हैं सीन और अन्य में 60 हर्ट्ज़ की दर से, लाइब्रेरी को इस इंटरवल में बदलाव करने की अनुमति मिल सकती है डाइनैमिक तौर पर इस्तेमाल किया जा सकता है.
  • बहुत तेज़ी से काम करने वाले फ़्रेम के लिए पाइपलाइनिंग बंद करें: बेहतर नतीजे देता है सभी मामलों में इनपुट-स्क्रीन इंतज़ार का समय.

एकाधिक रीफ़्रेश दरें

एक से ज़्यादा रीफ़्रेश दरों का इस्तेमाल करने वाले डिवाइसों में, आपको ज़्यादा कंट्रोल मिलता है स्वैप करने का ऐसा इंटरवल चुनना जो सही लग रहा हो:

  • 60 हर्ट्ज़ वाले डिवाइसों पर: 60 FPS / 30 FPS / 20 FPS
  • 60 हर्ट्ज़ + 90 हर्ट्ज़ वाले डिवाइसों पर: 90 FPS / 60 FPS / 45 FPS / 30 FPS
  • 60 हर्ट्ज़ + 90 हर्ट्ज़ + 120 हर्ट्ज़ वाले डिवाइसों पर चालू: 120 FPS / 90 FPS / 60 FPS / 45 FPS / 40 FPS / 30 FPS

लाइब्रेरी में रीफ़्रेश दर चुनी जाती है, जो असल रेंडरिंग से सबसे ज़्यादा मेल खाती है गेम के फ़्रेम की कुल अवधि को दिखाता है, जिससे बेहतर विज़ुअल अनुभव मिलता है.

रीफ़्रेश दर के अलग-अलग फ़्रेम पेसिंग के बारे में ज़्यादा जानकारी के लिए, Android पर ज़्यादा रीफ़्रेश दर वाली रेंडरिंग ब्लॉग पोस्ट.

फ़्रेम के आंकड़े

फ़्रेम पेसिंग लाइब्रेरी में डीबग करने और प्रोफ़ाइल बनाने के लिए:

  • स्क्रीन की संख्या का हिस्टोग्राम, उस फ़्रेम को रीफ़्रेश करता है जिसका इंतज़ार किया गया रेंडरिंग पूरी होने के बाद कंपोज़िटर की सूची में.
  • अनुरोध किए गए के बीच में पास की गई स्क्रीन रीफ़्रेश की संख्या का हिस्टोग्राम प्रज़ेंटेशन का समय और असल मौजूदा समय.
  • लगातार दो के बीच पास की गई स्क्रीन रीफ़्रेश की संख्या का हिस्टोग्राम फ़्रेम.
  • नए वर्शन की शुरुआत के बीच, स्क्रीन रीफ़्रेश की संख्या का हिस्टोग्राम सीपीयू (CPU), इस फ़्रेम के लिए और मौजूदा समय के हिसाब से काम करता है.

अगला चरण

Android फ़्रेम पेसिंग लाइब्रेरी को इंटिग्रेट करने के लिए, इन गाइड में से कोई एक देखें अपने गेम में शामिल करें: