2009-12-25 14 views
8

मैं वर्तमान में एक सॉफ्टवेयर कीबोर्ड (कुछ परिष्कृत भविष्यवाणी का उपयोग करके) को कार्यान्वित कर रहा हूं, और इसे कैनवास का उपयोग करके ड्राइंग करना perfomance के मामले में अपर्याप्त है। मुझे फ्रेम ड्राइंग के समय 100ms से ऊपर मिल रहा है, जो स्पष्ट रूप से अस्वीकार्य है।एंड्रॉइड पर ओपनजीएल एक बैटरी हत्यारा है?

कीबोर्ड में स्वयं लगभग 33 कुंजी होते हैं, उनमें से प्रत्येक ड्रॉराउंडरक्ट का उपयोग करके खींचा जाता है और उसके ऊपर एक साधारण पाठ होता है। कोई भी विजेट जो भी उपयोग नहीं किया जाता है, इसलिए यह सादा perfomance है। इसके अलावा, लगभग सभी गूगल्स परफॉर्मेंस टिप्स उपयोग में हैं, इसलिए गति की वजह भी नहीं है।

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

जैसा कि मुझे उस विषय पर कोई पर्याप्त दस्तावेज नहीं मिला है, मुझे उम्मीद है कि यहां कोई मुझे सही दिशा में इंगित कर सकता है।

उत्तर

25

चाहे बैटरी को कितना नाली जाए, आप शायद ऐसा नहीं करना चाहते हैं क्योंकि अधिकांश मौजूदा डिवाइस एक साथ कई ओपनजीएल संदर्भों का समर्थन नहीं करते हैं, इसलिए आपका सॉफ्ट कीबोर्ड किसी भी एप्लिकेशन के साथ असंगत होगा अपने स्वयं के चित्र के लिए ओपनजीएल का उपयोग करना। इन उपकरणों पर ओपनजीएल संदर्भ केवल अग्रभूमि अनुप्रयोग के स्वामित्व में है; इसका उपयोग यूआई के माध्यमिक हिस्सों में नरम कीबोर्ड की तरह नहीं किया जा सकता है।

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

+0

मैं मानता हूं, निश्चित रूप से मेरे लिए अनुकूलन के कुछ साधन शेष हैं। मैं अब के लिए बिटमैप ब्लिट्ज पर एक नज़र डालने जा रहा हूं और इसके अलावा कहने के लिए क्या छोड़ दिया गया है: धन्यवाद, और क्रिसमस का आनंद लें (हम यहां जर्मनी में बहुत गंभीरता से लेते हैं .. :-)) – moritz

+0

दिलचस्प दृष्टिकोण और पहलू .. यहां सीखने के लिए हर रोज कुछ नया ..;) अच्छा जवाब! 10q – Ewoks

+0

नोट: यह उत्तर 200 9 से है। आधुनिक डिवाइस एकाधिक जीएलएस संदर्भों का समर्थन करते हैं, और एक कस्टम व्यू पर कैनवास के साथ प्रतिपादन चीजों को गति देने के लिए जीएलएस का उपयोग कर सकते हैं (http://developer.android.com/guide/topics/graphics/hardware -accel.html)। – fadden

4

एक तरफ: क्या आपने एक बार चाबियाँ प्रस्तुत करने पर विचार किया है और फिर उन्हें स्प्राइट्स के रूप में पकड़कर इन्हें मारना है? यह वेक्टर ग्राफिक्स को प्रस्तुत करने के लिए काफी बेहतर होना चाहिए।

मैं आपको कठोर संख्या नहीं दे सकता (और जैसा कि एपहेकर ने बताया है, यह डिवाइस-विशिष्ट है), लेकिन अगर ओपनजीएल हार्डवेयर-त्वरित है और इसलिए बैटरी अधिक उपयोग कर सकती है, तो ऑपरेशन बहुत तेज हो जाना चाहिए और इसलिए कम शक्ति का उपयोग करना चाहिए कुल मिलाकर। यदि यह हार्डवेयर-त्वरित नहीं है, तो यह तार्किक लगता है कि ऑपरेशन को पूरा करने में अधिक समय लगने पर इसे और अधिक शक्ति का उपयोग करना चाहिए, क्योंकि आप केवल एक ड्राइंग एपीआई का आदान-प्रदान कर रहे हैं। सब कुछ, जैसा कि आपको केवल बाहरी घटनाओं के दौरान आकर्षित करना पड़ता है, इसे लंबे समय तक ज्यादा महत्व नहीं देना चाहिए, क्योंकि लोग शायद प्रति मिनट केवल कुछ चाबियाँ टिप रहे हैं।

आपको शायद इसे लागू करना होगा (शायद सरलीकृत परीक्षण मामले में) और माप करें।

+0

आपके उत्तर के लिए बहुत बहुत धन्यवाद, लेकिन हैकबोड की जानकारी पर विचार करते हुए, ऐसा लगता है जैसे ओपनजी समाधान नहीं है (जैसा कि यह सुखद होगा ..)। मेरी क्रिसमस, बीटीडब्ल्यू। – moritz

संबंधित मुद्दे