OpenGLRenderer কনফিগারেশন

এই ডকুমেন্টটিতে হার্ডওয়্যারের পারফরম্যান্স অপ্টিমাইজ করার জন্য পারফরম্যান্স টিউনিং বর্ণনা করা হয়েছে।

OpenGLRenderer (libhwui) বৈশিষ্ট্য

This document describes properties for controlling Android's 2D hardware-accelerated rendering pipeline. Set these properties in the device.mk as PRODUCT_PROPERTY_OVERRIDES .

সকল অ্যান্ড্রয়েড সংস্করণের জন্য বৈশিষ্ট্যসমূহ

সম্পত্তি প্রকার ডিফল্ট মান বর্ণনা
ro.zygote.disable_gl_preload boolean false বুট করার সময় জাইগোটে EGL/GL ড্রাইভার প্রি-লোডিং সক্ষম বা অক্ষম করে। যখন এই প্রপার্টিটি false হয়, তখন জাইগোট eglGetDisplay(EGL_DEFAULT_DISPLAY) কল করে GL ড্রাইভারগুলি প্রি-লোড করে। এটি অন্যান্য সমস্ত প্রসেসের সাথে শেয়ার করার জন্য জাইগোটে ডায়নামিক লাইব্রেরি কোড লোড করে। যদি কোনো ড্রাইভার শেয়ারিং সমর্থন না করে, তাহলে এই প্রপার্টিটি true সেট করুন।

অ্যান্ড্রয়েড ৮.০ এবং তার নিচের সংস্করণের জন্য প্রোপার্টিজ

সম্পত্তি প্রকার ডিফল্ট মান বর্ণনা
ro.hwui.disable_scissor_opt boolean false

সিজার অপটিমাইজেশন চালু বা বন্ধ করে। গ্রহণযোগ্য মানগুলো হলো true এবং false । যখন সিজার অপটিমাইজেশন চালু করা হয়, OpenGLRenderer বেছে বেছে GL সিজার টেস্ট চালু ও বন্ধ করার মাধ্যমে সিজারিং কমানোর চেষ্টা করে।

নিষ্ক্রিয় করা হলে, OpenGLRenderer জিএল সিজার টেস্ট সক্রিয় রাখে এবং প্রয়োজন অনুযায়ী সিজার রেক্ট পরিবর্তন করে। কিছু জিপিইউ (উদাহরণস্বরূপ, SGX 540) ঘন ঘন সিজার টেস্ট সক্রিয় বা নিষ্ক্রিয় করার চেয়ে সিজার রেক্ট বেশিবার পরিবর্তন করলে আরও ভালো পারফর্ম করে।

ro.hwui.texture_cache_size float 24 এটি প্রতি-প্রসেস টেক্সচার ক্যাশের আকার মেগাবাইটে নির্ধারণ করে। আমরা এমন একটি ক্যাশ ব্যবহার করার পরামর্শ দিই যা একাধিক স্ক্রিনের ৩২-বিট টেক্সচার ধারণ করতে পারে। উদাহরণস্বরূপ, একটি ১২৮০x৮০০ ডিসপ্লেতে, একটি সম্পূর্ণ স্ক্রিন বাফার প্রায় ৪ মেগাবাইট জায়গা নেয়, তাই ক্যাশটি কমপক্ষে ২০ মেগাবাইট হওয়া উচিত।
ro.hwui.layer_cache_size float 16 এটি প্রতি-প্রসেস লেয়ারের ক্যাশের আকার মেগাবাইটে নির্ধারণ করে। আমরা ৩২ বিটে স্ক্রিনের চারগুণ ডেটা ধারণ করতে পারে এমন একটি ক্যাশ ব্যবহার করার পরামর্শ দিই। উদাহরণস্বরূপ, একটি ১২৮০x৮০০ ডিসপ্লেতে, একটি সম্পূর্ণ স্ক্রিন বাফার প্রায় ৪ মেগাবাইট জায়গা নেয়, তাই ক্যাশটি কমপক্ষে ১৬ মেগাবাইট হওয়া উচিত।
ro.hwui.gradient_cache_size float 0.5 এটি প্রতি-প্রসেস গ্রেডিয়েন্ট ক্যাশের আকার মেগাবাইটে নির্ধারণ করে। একটি গ্রেডিয়েন্ট সাধারণত ১ কিলোবাইট থেকে ৪ কিলোবাইট মেমরি দখল করে। আমরা কমপক্ষে ১২টি গ্রেডিয়েন্ট ধারণ করতে পারে এমন একটি বড় ক্যাশ ব্যবহার করার পরামর্শ দিই।
ro.hwui.patch_cache_size integer 128 এটি প্রতি প্রসেসের জন্য ৯-প্যাচ ক্যাশের আকার কিলোবাইটে নির্ধারণ করে। এই ক্যাশে শুধুমাত্র ভার্টেক্স ডেটা ধারণ করে, তাই এটিকে ছোট রাখা যায়। প্রতিটি ভার্টেক্স ৪টি ফ্লোট বা ১৬ বাইট নিয়ে গঠিত।
ro.hwui.path_cache_size float 4 এটি প্রতি-প্রসেস পাথ ক্যাশের আকার মেগাবাইটে নির্ধারণ করে। আমরা এমন একটি ক্যাশ ব্যবহার করার পরামর্শ দিই যা অন্তত একটি স্ক্রিনের ৩২-বিট টেক্সচার ধারণ করতে পারে। উদাহরণস্বরূপ, একটি ১২৮০x৮০০ ডিসপ্লেতে, একটি সম্পূর্ণ স্ক্রিন বাফার প্রায় ৪ মেগাবাইট জায়গা নেয়, তাই ক্যাশটিও অন্তত ৪ মেগাবাইটের হওয়া উচিত।
ro.hwui.shape_cache_size float 1 এটি প্রতি-প্রসেস শেপ ক্যাশের আকার মেগাবাইটে নির্ধারণ করে। এই মানটি বৃত্ত এবং গোলাকার আয়তক্ষেত্রের মতো বিভিন্ন ক্যাশে ব্যবহার করা হয়। আমরা অন্তত একটি ৮-বিট স্ক্রিন ধারণ করার মতো যথেষ্ট বড় একটি ক্যাশে ব্যবহার করার পরামর্শ দিই। উদাহরণস্বরূপ, একটি ১২৮০x৮০০ ডিসপ্লেতে, একটি সম্পূর্ণ স্ক্রিন বাফার প্রায় ১ মেগাবাইট ব্যবহার করে, তাই ক্যাশেটির আকার অন্তত ১ মেগাবাইট হওয়া উচিত।
ro.hwui.drop_shadow_cache_size float 2 এটি প্রতি-প্রসেস টেক্সট ড্রপ শ্যাডো ক্যাশের আকার মেগাবাইটে নির্ধারণ করে। আমরা দুটি স্ক্রিনের ৮-বিট টেক্সচার ধারণ করার মতো যথেষ্ট বড় একটি ক্যাশ ব্যবহার করার পরামর্শ দিই। উদাহরণস্বরূপ, একটি ১২৮০x৮০০ ডিসপ্লেতে, একটি সম্পূর্ণ স্ক্রিন বাফার প্রায় ১ মেগাবাইট জায়গা নেয়, তাই ক্যাশটি কমপক্ষে ২ মেগাবাইট হওয়া উচিত।
ro.hwui.r_buffer_cache_size float 2 এটি প্রতি-প্রসেস রেন্ডার বাফার ক্যাশের আকার মেগাবাইটে নির্ধারণ করে। আমরা এমন একটি ক্যাশ ব্যবহার করার পরামর্শ দিই যা ৮ বিটে স্ক্রিনের দ্বিগুণ ধারণ করতে পারে। উদাহরণস্বরূপ, একটি 1280x800 ডিসপ্লেতে, একটি পূর্ণ স্ক্রিন বাফার প্রায় ১ মেগাবাইট ব্যবহার করে, তাই ক্যাশটি কমপক্ষে ২ মেগাবাইট হওয়া উচিত। যদি ডিভাইসটি ৪-বিট বা ১-বিট স্টেনসিল বাফার সমর্থন করে, তবে ক্যাশটি আরও ছোট হতে পারে।
ro.hwui.texture_cache_flush_rate float 0.6 মেমরি ফ্লাশ করার পর টেক্সচার ক্যাশের কত শতাংশ ধরে রাখা হবে, তা এটি নির্ধারণ করে। যখন সমস্ত অ্যাপ্লিকেশন জুড়ে মেমরি পুনরুদ্ধার করার প্রয়োজন হয়, তখন সিস্টেম মেমরি ফ্লাশ করে। এই ধরনের পরিস্থিতিতে আমরা প্রায় ৫০% ক্যাশ রিলিজ করার পরামর্শ দিই।
ro.hwui.text_small_cache_width integer 1024 ডিফল্ট ফন্ট ক্যাশের প্রস্থ পিক্সেলে নির্ধারণ করে। এর সর্বোচ্চ সীমা নির্ভর করে জিপিইউ কত দ্রুত টেক্সচার আপলোড করতে পারে তার উপর। আমরা কমপক্ষে ১০২৪ পিক্সেল কিন্তু সর্বোচ্চ ২০৪৮ পিক্সেল ব্যবহার করার পরামর্শ দিই। এছাড়াও, মানটি দুই-এর ঘাত (power-of-two) হতে হবে।
ro.hwui.text_small_cache_height integer 256 ডিফল্ট ফন্ট ক্যাশের উচ্চতা পিক্সেলে নির্ধারণ করে। এর সর্বোচ্চ সীমা নির্ভর করে জিপিইউ কত দ্রুত টেক্সচার আপলোড করতে পারে তার উপর। আমরা কমপক্ষে ২৫৬ পিক্সেল কিন্তু সর্বোচ্চ ১০২৪ পিক্সেল ব্যবহার করার পরামর্শ দিই।
ro.hwui.text_large_cache_width integer 2048 এটি বড় ফন্ট ক্যাশের প্রস্থ (পিক্সেল-এ) নির্ধারণ করে। এই ক্যাশটি সেইসব গ্লিফ-এর জন্য ব্যবহৃত হয় যেগুলো ডিফল্ট ফন্ট ক্যাশে জায়গা পাওয়ার জন্য অনেক বড়। এর সর্বোচ্চ সীমা নির্ভর করে জিপিইউ (GPU) কত দ্রুত টেক্সচার আপলোড করতে পারে তার উপর। আমরা কমপক্ষে ২০৪৮ পিক্সেল কিন্তু সর্বোচ্চ ৪০৯৬ পিক্সেল ব্যবহার করার পরামর্শ দিই। এছাড়াও, মানটি দুই-এর ঘাত (power-of-two) হতে হবে।
ro.hwui.text_large_cache_height integer 512 এটি লার্জ ফন্ট ক্যাশের উচ্চতা পিক্সেলে নির্ধারণ করে। যেসব গ্লিফ ডিফল্ট ফন্ট ক্যাশে জায়গা পাওয়ার জন্য অনেক বড়, সেগুলোর জন্য লার্জ ফন্ট ক্যাশ ব্যবহার করা হয়। এর সর্বোচ্চ সীমা নির্ভর করে জিপিইউ কত দ্রুত টেক্সচার আপলোড করতে পারে তার উপর। আমরা কমপক্ষে ৫১২ পিক্সেল কিন্তু সর্বোচ্চ ২০৪৮ পিক্সেল ব্যবহার করার পরামর্শ দিই। এছাড়াও, মানটি দুই-এর ঘাত (power-of-two) হতে হবে।
hwui.text_gamma_correction string lookup টেক্সট গামা সংশোধন কৌশল নির্বাচন করে। চারটি সম্ভাব্য বিকল্প রয়েছে:
  • lookup3 : লুকআপ টেবিলের উপর ভিত্তি করে একটি সংশোধন। কালো এবং সাদা টেক্সটের জন্য গামা সংশোধন ভিন্ন হয় (নিম্নলিখিত থ্রেশহোল্ডগুলি দেখুন)।
  • lookup : একটিমাত্র লুকআপ টেবিলের উপর ভিত্তি করে করা সংশোধন।
  • shader3 : একটি GLSL shader দ্বারা প্রয়োগ করা সংশোধন। কালো এবং সাদা টেক্সটের জন্য গামা সংশোধন ভিন্ন হয় (নিম্নলিখিত থ্রেশহোল্ডগুলি দেখুন)।
  • shader : একটি GLSL শেডার দ্বারা প্রয়োগ করা সংশোধন।
সীমিত শেডার ম্যাথযুক্ত জিপিইউ-তে লুকআপ গামা কারেকশন সবচেয়ে ভালোভাবে কাজ করে। মেমরি সাশ্রয়ের জন্য শেডার গামা কারেকশন সবচেয়ে ভালো। আমরা ডিফল্ট lookup টেকনিক ব্যবহার করার পরামর্শ দিই, যা কোয়ালিটি, স্পিড এবং মেমরি ব্যবহারের দিক থেকে একটি ভালো সমন্বয় প্রদান করে।
hwui.text_gamma float 1.4 টেক্সট গামা সংশোধনের জন্য ব্যবহৃত গামা মান নির্ধারণ করে। আপনি ডিভাইসের ডিসপ্লে অনুযায়ী এই মানটি সামঞ্জস্য করতে পারেন।
hwui.text_gamma.black_threshold integer 64 এটি সেই উজ্জ্বলতার সীমা নির্ধারণ করে, যার নিচে ব্ল্যাক গামা কারেকশন প্রয়োগ করা হয়। মানটি অবশ্যই ০-২৫৫ পরিসরের মধ্যে হতে হবে।
hwui.text_gamma.white_threshold integer 192 এটি সেই উজ্জ্বলতার সীমা নির্ধারণ করে, যার উপরে সাদা গামা সংশোধন প্রয়োগ করা হয়। মানটি অবশ্যই ০-২৫৫ পরিসরের মধ্যে হতে হবে।
hwui.use_gpu_pixel_buffers boolean true OpenGL ES 3.0 হার্ডওয়্যারে PBO-এর ব্যবহার সক্ষম বা অক্ষম করে। রেন্ডারার অ্যাসিঙ্ক্রোনাস টেক্সচার আপলোড করার জন্য, বিশেষ করে ফন্ট ক্যাশের জন্য, PBO ব্যবহার করে। এই প্রপার্টিটি সর্বদা সক্ষম থাকা উচিত, কিন্তু PBO-এর কারণে কোনো ত্রুটি বা দুর্বল পারফরম্যান্স দেখা দিলে আপনি ব্রিংআপ বা ডেভেলপমেন্টের সময় এটি অক্ষম করতে পারেন। এই কারণেই প্রপার্টিটি রিড-অনলি নয়।