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

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

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

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

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

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

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

सिस्ट्रेस के साथ बफ़रक्यू को ट्रैक करें

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

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

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

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

ग्रालोक

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

• सॉफ़्टवेयर (सीपीयू) से मेमोरी को कितनी बार एक्सेस किया जाएगा
• हार्डवेयर (जीपीयू) से मेमोरी को कितनी बार एक्सेस किया जाएगा
• क्या मेमोरी का उपयोग ओपनजीएल ईएस (जीएलईएस) बनावट के रूप में किया जाएगा
• क्या मेमोरी का उपयोग वीडियो एनकोडर द्वारा किया जाएगा

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

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

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

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

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

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

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