बफ़रक्यू और ग्रालोक

बफ़रक्यू वर्ग उन घटकों को जोड़ता है जो ग्राफिकल डेटा ( निर्माता ) के बफ़र्स को उन घटकों से जोड़ते हैं जो डेटा को प्रदर्शन या आगे की प्रक्रिया ( उपभोक्ता ) के लिए स्वीकार करते हैं। सिस्टम के माध्यम से ग्राफिकल डेटा के बफ़र्स को स्थानांतरित करने वाली लगभग हर चीज़ बफ़रक्यू पर निर्भर करती है।

ग्रेलोक मेमोरी एलोकेटर बफर आवंटन करता है और दो विक्रेता-विशिष्ट एचआईडीएल इंटरफेस के माध्यम से कार्यान्वित किया जाता है ( hardware/interfaces/graphics/allocator/ और hardware/interfaces/graphics/mapper/ देखें)। allocate() फ़ंक्शन अपेक्षित तर्क (चौड़ाई, ऊंचाई, पिक्सेल प्रारूप) के साथ-साथ उपयोग झंडे का एक सेट लेता है।

बफ़रक्यू निर्माता और उपभोक्ता

उपभोक्ता बफ़रक्यू डेटा संरचना बनाते हैं और उसके मालिक होते हैं और अपने उत्पादकों की तुलना में विभिन्न प्रक्रियाओं में मौजूद हो सकते हैं। जब किसी निर्माता को बफ़र की आवश्यकता होती है, तो वह बफ़र की चौड़ाई, ऊँचाई, पिक्सेल प्रारूप और उपयोग फ़्लैग को निर्दिष्ट करते हुए dequeueBuffer() को कॉल करके बफ़रक्यू से एक मुफ़्त बफ़र का अनुरोध करता है। निर्माता तब बफर को पॉप्युलेट करता है और queueBuffer() को कॉल करके बफर को कतार में लौटाता है। इसके बाद, उपभोक्ता अधिग्रहणबफर acquireBuffer() के साथ बफर प्राप्त करता है और बफर सामग्री का उपयोग करता है। जब उपभोक्ता किया जाता है, तो यह releaseBuffer() को कॉल करके बफर को कतार में वापस कर देता है। सिंक फ्रेमवर्क नियंत्रित करता है कि बफ़र्स एंड्रॉइड ग्राफिक्स पाइपलाइन के माध्यम से कैसे आगे बढ़ते हैं।

बफ़रक्यू की कुछ विशेषताएं, जैसे कि बफ़र्स की अधिकतम संख्या जो इसे धारण कर सकती है, निर्माता और उपभोक्ता द्वारा संयुक्त रूप से निर्धारित की जाती है। हालाँकि, BufferQueue बफ़र्स को उनकी आवश्यकता के अनुसार आवंटित करता है। बफ़र्स को तब तक बनाए रखा जाता है जब तक कि विशेषताएँ नहीं बदल जातीं; उदाहरण के लिए, यदि कोई निर्माता अलग-अलग आकार के बफ़र्स का अनुरोध करता है, तो पुराने बफ़र्स मुक्त हो जाते हैं और माँग पर नए बफ़र्स आवंटित किए जाते हैं।

बफ़र सामग्री को बफ़रक्यू द्वारा कभी भी कॉपी नहीं किया जाता है, क्योंकि इतना डेटा इधर-उधर ले जाना अक्षम है। इसके बजाय, बफ़र्स को हमेशा एक हैंडल द्वारा पास किया जाता है।

सिस्ट्रेस के साथ ट्रैकिंग BufferQueue

यह समझने के लिए कि ग्राफिक्स बफ़र्स कैसे घूमते हैं, सिस्ट्रेस का उपयोग करें, एक उपकरण जो कम समय में डिवाइस गतिविधि को रिकॉर्ड करता है। सिस्टम-स्तरीय ग्राफिक्स कोड अच्छी तरह से इंस्ट्रुमेंटेड है, जैसा कि अधिकांश प्रासंगिक ऐप फ्रेमवर्क कोड है।

सिस्ट्रेस का उपयोग करने के लिए, gfx , view , और sched टैग्स को सक्षम करें। BufferQueue ऑब्जेक्ट ट्रेस में प्रदर्शित होते हैं। उदाहरण के तौर पर, यदि आप ग्राफ़िका के प्ले वीडियो (सरफेस व्यू) के चलने के दौरान ट्रेस लेते हैं, तो सर्फेस व्यू लेबल वाली पंक्ति आपको बताती है कि किसी भी समय कितने बफ़र्स कतारबद्ध थे।

ऐप के सक्रिय होने पर मूल्य वृद्धि होती है, जो MediaCodec डिकोडर द्वारा फ़्रेम के प्रतिपादन को ट्रिगर करता है। सरफेसफ्लिंगर काम कर रहा है और बफर का उपभोग कर रहा है, जबकि मूल्य में कमी आई है। 30 एफपीएस पर वीडियो दिखाते समय, कतार का मान 0 से 1 तक भिन्न होता है क्योंकि ~ 60 एफपीएस डिस्प्ले स्रोत के साथ बना रह सकता है। सरफेसफ्लिंगर तभी जागता है जब काम करना होता है, प्रति सेकंड 60 बार नहीं। सिस्टम काम से बचने की कोशिश करता है और अगर स्क्रीन को कुछ भी अपडेट नहीं कर रहा है तो वीएसवाईएनसी को निष्क्रिय कर देता है।

यदि आप Grafika के प्ले वीडियो (TextureView) पर स्विच करते हैं और एक नया ट्रेस प्राप्त करते हैं, तो आपको com.android.grafika / com.android.grafika.PlayMovieActivity लेबल वाली एक पंक्ति दिखाई देती है। यह मुख्य UI परत है, जो एक और BufferQueue है। चूंकि TextureView एक अलग परत के बजाय UI परत में प्रस्तुत होता है, सभी वीडियो-चालित अपडेट यहां प्रदर्शित होते हैं।

ग्रालोक

ग्रैलोक आवंटक एचएएल hardware/libhardware/include/hardware/gralloc.h उपयोग झंडे के माध्यम से बफर आवंटन करता है। उपयोग के झंडे में विशेषताएं शामिल हैं जैसे:

• सॉफ़्टवेयर (CPU) से मेमोरी को कितनी बार एक्सेस किया जाएगा
• कितनी बार मेमोरी को हार्डवेयर (GPU) से एक्सेस किया जाएगा
• क्या स्मृति का उपयोग OpenGL ES (GLES) बनावट के रूप में किया जाएगा
• क्या वीडियो एन्कोडर द्वारा मेमोरी का उपयोग किया जाएगा

उदाहरण के लिए, यदि किसी निर्माता का बफर प्रारूप RGBA_8888 पिक्सेल निर्दिष्ट करता है, और निर्माता इंगित करता है कि बफर को सॉफ़्टवेयर से एक्सेस किया जाएगा (जिसका अर्थ है कि एक ऐप CPU पर पिक्सेल को स्पर्श करेगा), तो Gralloc RGBA क्रम में 4 बाइट्स प्रति पिक्सेल के साथ एक बफर बनाता है। यदि इसके बजाय, एक निर्माता निर्दिष्ट करता है कि इसके बफर को केवल हार्डवेयर से एक्सेस किया जाएगा और एक GLES बनावट के रूप में, Gralloc GLES ड्राइवर कुछ भी कर सकता है, जैसे कि BGRA ऑर्डरिंग, नॉनलाइनियर स्विज़ल्ड लेआउट और वैकल्पिक रंग प्रारूप। हार्डवेयर को उसके पसंदीदा प्रारूप का उपयोग करने की अनुमति देने से प्रदर्शन में सुधार हो सकता है।

कुछ मान कुछ प्लेटफ़ॉर्म पर संयोजित नहीं किए जा सकते. उदाहरण के लिए, वीडियो एन्कोडर फ़्लैग को YUV पिक्सेल की आवश्यकता हो सकती है, इसलिए सॉफ़्टवेयर एक्सेस जोड़ना और RGBA_8888 निर्दिष्ट करना विफल हो जाता है।

ग्रेलोक द्वारा लौटाए गए हैंडल को बाइंडर के माध्यम से प्रक्रियाओं के बीच पारित किया जा सकता है।

संरक्षित बफ़र्स

ग्रैलोक उपयोग ध्वज GRALLOC_USAGE_PROTECTED ग्राफिक्स बफर को केवल हार्डवेयर-संरक्षित पथ के माध्यम से प्रदर्शित करने की अनुमति देता है। ये ओवरले प्लेन DRM सामग्री को प्रदर्शित करने का एकमात्र तरीका हैं (DRM-संरक्षित बफ़र्स को SurfaceFlinger या OpenGL ES ड्राइवर द्वारा एक्सेस नहीं किया जा सकता है)।

DRM-रक्षित वीडियो केवल ओवरले प्लेन पर प्रस्तुत किया जा सकता है। संरक्षित सामग्री का समर्थन करने वाले वीडियो प्लेयर को SurfaceView के साथ लागू किया जाना चाहिए। असुरक्षित हार्डवेयर पर चलने वाला सॉफ़्टवेयर बफ़र को पढ़ या लिख ​​नहीं सकता; हार्डवेयर-संरक्षित पथ हार्डवेयर कम्पोज़र ओवरले पर दिखाई देने चाहिए (अर्थात, यदि हार्डवेयर कम्पोज़र OpenGL ES संरचना में स्विच करता है, तो संरक्षित वीडियो प्रदर्शन से गायब हो जाते हैं)।

संरक्षित सामग्री के विवरण के लिए, डीआरएम देखें।