OpenGLRenderer कॉन्फ़िगरेशन

यह दस्तावेज़ प्रदर्शन ट्यूनिंग का वर्णन करता है जिसे आप अपने हार्डवेयर से अधिकतम लाभ प्राप्त करने के लिए कर सकते हैं।

OpenGLRenderer (libhwui) गुण

यह दस्तावेज़ उन सभी गुणों को सूचीबद्ध करता है जिनका उपयोग आप Android के 2D हार्डवेयर त्वरित रेंडरिंग पाइपलाइन को नियंत्रित करने के लिए कर सकते हैं। इन गुणों को device.mk में PRODUCT_PROPERTY_OVERRIDES के रूप में सेट करें।

सभी Android संस्करणों के लिए गुण

संपत्ति प्रकार डिफ़ॉल्ट मान विवरण
ro.zygote.disable_gl_preload boolean false बूट समय पर Zygote में EGL/GL ड्राइवरों की प्रीलोडिंग को सक्षम/अक्षम करने के लिए उपयोग किया जाता है। जब यह प्रॉपर्टी गलत पर सेट हो जाती है, तो Zygote eglGetDisplay(EGL_DEFAULT_DISPLAY) को इनवॉइस करके GL ड्राइवर्स को प्रीलोड कर देगा। लक्ष्य डायनामिक लाइब्रेरी कोड को अन्य सभी प्रक्रियाओं के साथ साझा करने के लिए Zygote में लोड करना है। यदि कोई ड्राइवर साझा किए जाने का समर्थन नहीं करता है, तो इस संपत्ति को सत्य पर सेट करें।

एंड्रॉइड 8.0 और उससे पहले के संस्करण के लिए गुण

संपत्ति प्रकार डिफ़ॉल्ट मान विवरण
ro.hwui.disable_scissor_opt boolean false

कैंची अनुकूलन को सक्षम या अक्षम करने के लिए उपयोग किया जाता है। स्वीकृत मूल्य सत्य और असत्य हैं। जब कैंची अनुकूलन सक्षम होता है, तो OpenGLRenderer जीएल कैंची परीक्षण को चुनिंदा रूप से सक्षम और अक्षम करके कैंची के उपयोग को कम करने का प्रयास करता है।

जब अनुकूलन अक्षम हो जाता है, तो OpenGLRenderer GL कैंची परीक्षण को सक्षम रखता है और आवश्यकतानुसार कैंची को बदल देता है। कुछ जीपीयू (उदाहरण के लिए, एसजीएक्स 540) कैंची परीक्षण को अक्सर सक्षम या अक्षम करने की तुलना में कैंची रेक्ट को अधिक बार बदलने पर बेहतर प्रदर्शन करते हैं।

ro.hwui.texture_cache_size float 24 प्रति प्रक्रिया बनावट कैश के आकार को मेगाबाइट में परिभाषित करता है। हम 32-बिट बनावट के लायक कई स्क्रीन रखने के लिए पर्याप्त बड़े कैश का उपयोग करने की सलाह देते हैं (उदाहरण के लिए, 1280x800 डिस्प्ले पर, एक पूर्ण स्क्रीन बफर लगभग 4 एमबी का उपयोग करता है इसलिए कैश कम से कम 20 एमबी होना चाहिए।)
ro.hwui.layer_cache_size float 16 प्रति प्रोसेस लेयर कैश के आकार को मेगाबाइट में परिभाषित करता है। हम 32 बिट्स में 4 गुना स्क्रीन होल्ड करने के लिए पर्याप्त बड़े कैश का उपयोग करने की सलाह देते हैं। उदाहरण के लिए, 1280x800 डिस्प्ले पर, एक पूर्ण स्क्रीन बफ़र लगभग 4 एमबी का उपयोग करता है, इसलिए कैश कम से कम 16 एमबी होना चाहिए।
ro.hwui.gradient_cache_size 0.5 float प्रति प्रक्रिया ग्रेडिएंट कैश के आकार को मेगाबाइट में परिभाषित करता है। एक एकल ग्रेडिएंट आम तौर पर 1 और 4 केबी मेमोरी के बीच होता है। कम से कम बारह ग्रेडिएंट रखने के लिए पर्याप्त बड़े कैश का उपयोग करने की अनुशंसा की जाती है।
ro.hwui.patch_cache_size integer 128 प्रति प्रक्रिया, 9-पैच कैश के आकार को किलोबाइट में परिभाषित करता है। इस कैश में केवल वर्टेक्स डेटा होता है और इसलिए इसे छोटा रखा जा सकता है। प्रत्येक शीर्ष 4 फ्लोट्स या 16 बाइट्स से बना है।
ro.hwui.path_cache_size float 4 प्रति प्रक्रिया पथ कैश के आकार को मेगाबाइट में परिभाषित करता है। हमने कम से कम एक स्क्रीन लायक 32-बिट टेक्सचर रखने के लिए पर्याप्त बड़े कैश का उपयोग करने की अनुशंसा की है। उदाहरण के लिए, 1280x800 डिस्प्ले पर, एक पूर्ण स्क्रीन बफ़र लगभग 4 एमबी का उपयोग करता है, इसलिए कैश कम से कम 4 एमबी होना चाहिए।
ro.hwui.shape_cache_size float 1 प्रति प्रक्रिया कैश के आकार को मेगाबाइट में परिभाषित करता है। इस मान का उपयोग कई कैश जैसे वृत्त और गोलाकार आयतों द्वारा किया जाता है। हम कम से कम एक 8-बिट स्क्रीन रखने के लिए पर्याप्त बड़े कैश का उपयोग करने की सलाह देते हैं। उदाहरण के लिए, 1280x800 डिस्प्ले पर, एक पूर्ण स्क्रीन बफ़र लगभग 1 एमबी का उपयोग करता है, इसलिए कैश कम से कम 1 एमबी होना चाहिए।
ro.hwui.drop_shadow_cache_size float 2 प्रति प्रक्रिया टेक्स्ट ड्रॉप शैडो कैश के आकार को मेगाबाइट में परिभाषित करता है। हम 8-बिट बनावट वाली दो स्क्रीन रखने के लिए पर्याप्त बड़े कैश का उपयोग करने की सलाह देते हैं। उदाहरण के लिए, 1280x800 डिस्प्ले पर, एक पूर्ण स्क्रीन बफ़र लगभग 1 एमबी का उपयोग करता है, इसलिए कैश कम से कम 2 एमबी होना चाहिए।
ro.hwui.r_buffer_cache_size float 2 प्रति प्रक्रिया रेंडर बफ़र्स कैश के आकार को मेगाबाइट में परिभाषित करता है। 8 बिट्स में स्क्रीन को दोगुना रखने के लिए पर्याप्त बड़े कैश का उपयोग करने की अनुशंसा की जाती है। उदाहरण के लिए, 1280x800 डिस्प्ले पर, एक पूर्ण स्क्रीन बफ़र लगभग 1 एमबी का उपयोग करता है इसलिए कैश कम से कम 2 एमबी होना चाहिए। यदि डिवाइस 4 बिट या 1 बिट स्टेंसिल बफ़र्स का समर्थन करता है तो कैश छोटा हो सकता है।
ro.hwui.texture_cache_flush_rate float 0.6 मेमोरी फ्लश के बाद रखे जाने वाले टेक्सचर कैश के प्रतिशत को परिभाषित करता है। मेमोरी फ्लश तब ट्रिगर होता है जब सिस्टम को सभी अनुप्रयोगों में मेमोरी पुनः प्राप्त करने की आवश्यकता होती है। हम ऐसी स्थितियों में लगभग 50% कैश जारी करने की अनुशंसा करते हैं।
ro.hwui.text_small_cache_width integer 1024 डिफ़ॉल्ट फ़ॉन्ट कैश के पिक्सेल में चौड़ाई को परिभाषित करता है। ऊपरी सीमा इस बात पर निर्भर करती है कि GPU कितनी तेजी से बनावट अपलोड कर सकता है। हम कम से कम 1024 पिक्सेल लेकिन अधिकतम 2048 पिक्सेल का उपयोग करने की अनुशंसा करते हैं। आपको दो मान की शक्ति का भी उपयोग करना चाहिए।
ro.hwui.text_small_cache_height integer 256 डिफ़ॉल्ट फ़ॉन्ट कैश के पिक्सेल में ऊंचाई को परिभाषित करता है। ऊपरी सीमा इस बात पर निर्भर करती है कि GPU कितनी तेजी से बनावट अपलोड कर सकता है। हम कम से कम 256 पिक्सेल लेकिन अधिकतम 1024 पिक्सेल का उपयोग करने की अनुशंसा करते हैं।
ro.hwui.text_large_cache_width integer 2048 बड़े फ़ॉन्ट कैश के पिक्सेल में चौड़ाई को परिभाषित करता है। इस कैश का उपयोग डिफ़ॉल्ट फ़ॉन्ट कैश में फ़िट होने के लिए बहुत बड़े ग्लिफ़ के लिए किया जाता है। ऊपरी सीमा इस बात पर निर्भर करती है कि GPU कितनी तेजी से बनावट अपलोड कर सकता है। हमने कम से कम 2048 पिक्सेल लेकिन अधिकतम 4096 पिक्सेल का उपयोग करने की अनुशंसा की है। आपको दो मान की शक्ति का भी उपयोग करना चाहिए।
ro.hwui.text_large_cache_height integer 512 बड़े फ़ॉन्ट कैश के पिक्सेल में ऊंचाई को परिभाषित करता है। डिफ़ॉल्ट फ़ॉन्ट कैश में फ़िट होने के लिए बहुत बड़े ग्लिफ़ के लिए बड़े फ़ॉन्ट कैश का उपयोग किया जाता है। ऊपरी सीमा इस बात पर निर्भर करती है कि GPU कितनी तेजी से बनावट अपलोड कर सकता है। हम कम से कम 512 पिक्सेल लेकिन अधिकतम 2048 पिक्सेल का उपयोग करने की अनुशंसा करते हैं। आपको दो मान की शक्ति का भी उपयोग करना चाहिए।
hwui.text_gamma_correction string lookup टेक्स्ट गामा सुधार तकनीक का चयन करता है। चार संभावित विकल्प हैं:
  • lookup3 : लुकअप तालिकाओं पर आधारित एक सुधार। काले और सफेद पाठ के लिए गामा सुधार अलग है (नीचे सीमाएँ देखें)।
  • lookup : एकल लुकअप तालिका पर आधारित एक सुधार।
  • shader3 : जीएलएसएल शेडर द्वारा लागू किया गया सुधार। काले और सफेद पाठ के लिए गामा सुधार अलग है (नीचे सीमाएँ देखें)।
  • shader : जीएलएसएल शेडर द्वारा लागू किया गया सुधार।
लुकअप गामा सुधार सीमित शेडर गणित वाले जीपीयू पर सबसे अच्छा काम करता है। मेमोरी को बचाने के लिए शेडर गामा सुधार सर्वोत्तम हैं। हम डिफ़ॉल्ट lookup तकनीक का उपयोग करने की सलाह देते हैं, जो गुणवत्ता, गति और मेमोरी उपयोग के मामले में अच्छा समझौता प्रदान करती है।
hwui.text_gamma float 1.4 पाठ गामा सुधार के लिए प्रयुक्त गामा मान को परिभाषित करता है। इस मान को डिवाइस द्वारा उपयोग किए जाने वाले डिस्प्ले के आधार पर समायोजित किया जा सकता है।
hwui.text_gamma.black_threshold integer 64 चमक सीमा को परिभाषित करता है जिसके नीचे काला गामा सुधार लागू किया जाता है। मान को 0..255 की श्रेणी में परिभाषित किया जाना चाहिए।
hwui.text_gamma.white_threshold integer 192 चमक सीमा को परिभाषित करता है जिसके ऊपर सफेद गामा सुधार लागू किया जाता है। मान को 0..255 की श्रेणी में परिभाषित किया जाना चाहिए।
hwui.use_gpu_pixel_buffers boolean true OpenGL ES 3.0 हार्डवेयर पर PBO के उपयोग को सक्षम या अक्षम करने के लिए उपयोग किया जाता है। पीबीओ का उपयोग रेंडरर द्वारा अतुल्यकालिक बनावट अपलोड करने के लिए किया जाता है, विशेष रूप से फ़ॉन्ट कैश के लिए। यह संपत्ति हमेशा सक्षम रहनी चाहिए लेकिन यदि पीबीओ के उपयोग से भ्रष्टाचार या भयानक प्रदर्शन होता है तो इसे लाने या विकास के दौरान अक्षम किया जा सकता है। यही कारण है कि संपत्ति केवल पढ़ने योग्य नहीं है।