ব্লিঙ্ক ক্রোমিয়ামের ওয়েব প্ল্যাটফর্মের বাস্তবায়নকে বোঝায়, এবং এটি কম্পোজিট করার পূর্বে রেন্ডারিংয়ের সমস্ত পর্যায়গুলিকে অন্তর্ভুক্ত করে, যা কম্পোজিটর কমিটের মধ্যে শেষ হয়৷ আপনি এই সিরিজের পূর্ববর্তী নিবন্ধে ব্লিঙ্ক রেন্ডারিং আর্কিটেকচার সম্পর্কে আরও পড়তে পারেন।
ব্লিঙ্কের জীবন শুরু হয়েছিল WebKit- এর একটি কাঁটা হিসাবে, যেটি নিজেই KHTML- এর একটি কাঁটা, যেটি 1998 সালের। এটিতে ক্রোমিয়ামের কিছু প্রাচীন (এবং সবচেয়ে সমালোচনামূলক) কোড রয়েছে এবং 2014 সাল নাগাদ এটি অবশ্যই তার বয়স দেখাচ্ছে। সেই বছরে, ব্লিঙ্ক কোডের সংগঠন এবং কাঠামোর দীর্ঘস্থায়ী ঘাটতিগুলিকে সমাধান করার লক্ষ্যে আমরা যেটিকে ব্লিঙ্কএনজি বলছি তার ব্যানারে আমরা উচ্চাভিলাষী প্রকল্পগুলির একটি সেট শুরু করেছি। এই নিবন্ধটি ব্লিঙ্কএনজি এবং এর উপাদান প্রকল্পগুলি অন্বেষণ করবে: কেন আমরা সেগুলি করেছি, তারা কী করেছে, নির্দেশক নীতিগুলি যা তাদের নকশাকে আকার দিয়েছে এবং ভবিষ্যতের উন্নতির সুযোগগুলি তাদের সামর্থ্য রয়েছে৷
প্রি-এনজি রেন্ডারিং
ব্লিঙ্কের মধ্যে রেন্ডারিং পাইপলাইনটি সর্বদা ধারণাগতভাবে পর্যায়ক্রমে বিভক্ত ছিল ( শৈলী , বিন্যাস , পেইন্ট , এবং তাই), কিন্তু বিমূর্ততা বাধাগুলি ফুটো ছিল। বিস্তৃতভাবে বলতে গেলে, রেন্ডারিংয়ের সাথে যুক্ত ডেটা দীর্ঘজীবী, পরিবর্তনযোগ্য বস্তু নিয়ে গঠিত। এই বস্তুগুলি যেকোন সময়ে পরিবর্তিত হতে পারে—এবং সংশোধিত হতে পারে, এবং ক্রমাগত রেন্ডারিং আপডেটের মাধ্যমে ঘন ঘন পুনর্ব্যবহৃত এবং পুনঃব্যবহার করা হয়। নির্ভরযোগ্যভাবে সহজ প্রশ্নের উত্তর দেওয়া অসম্ভব ছিল যেমন:
- শৈলী, বিন্যাস, বা পেইন্টের আউটপুট কি আপডেট করা দরকার?
- এই ডেটা কখন তাদের "চূড়ান্ত" মান পাবে?
- কখন এই ডেটা পরিবর্তন করা ঠিক হবে?
- এই বস্তুটি কখন মুছে ফেলা হবে?
এর অনেক উদাহরণ রয়েছে, যার মধ্যে রয়েছে:
স্টাইল স্টাইলশীটের উপর ভিত্তি করে ComputedStyle তৈরি করবে; কিন্তু ComputedStyle অপরিবর্তনীয় ছিল না; কিছু ক্ষেত্রে এটি পরবর্তী পাইপলাইন পর্যায়ের দ্বারা সংশোধন করা হবে।
শৈলী LayoutObject এর একটি ট্রি তৈরি করবে এবং তারপর বিন্যাস সেই বস্তুগুলিকে আকার এবং অবস্থানগত তথ্য সহ টীকা করবে। কিছু ক্ষেত্রে, লেআউট এমনকি গাছের গঠন পরিবর্তন করবে। লেআউটের ইনপুট এবং আউটপুটগুলির মধ্যে কোনও স্পষ্ট বিচ্ছেদ ছিল না।
স্টাইল আনুষঙ্গিক ডেটা স্ট্রাকচার তৈরি করবে যা কম্পোজিটিং এর কোর্স নির্ধারণ করে এবং সেই ডাটা স্ট্রাকচারগুলি স্টাইলের পরে প্রতিটি ধাপে পরিবর্তন করা হয়।
একটি নিম্ন স্তরে, রেন্ডারিং ডেটা টাইপগুলি মূলত বিশেষায়িত গাছগুলি নিয়ে গঠিত (উদাহরণস্বরূপ, DOM ট্রি, স্টাইল ট্রি, লেআউট ট্রি, পেইন্ট প্রোপার্টি ট্রি); এবং রেন্ডারিং পর্যায়গুলি পুনরাবৃত্তিমূলক ট্রি ওয়াক হিসাবে প্রয়োগ করা হয়। আদর্শভাবে, একটি ট্রি ওয়াক থাকা উচিত: একটি প্রদত্ত ট্রি নোড প্রক্রিয়া করার সময়, আমাদের সেই নোডে থাকা সাবট্রির বাইরে কোনো তথ্য অ্যাক্সেস করা উচিত নয়। এটা সত্য প্রি-রেন্ডারিংএনজি ছিল না; গাছ প্রক্রিয়াজাত করা নোডের পূর্বপুরুষদের কাছ থেকে প্রায়শই অ্যাক্সেস করা তথ্য পায়। এটি সিস্টেমটিকে খুব ভঙ্গুর এবং ত্রুটি-প্রবণ করে তুলেছে। গাছের শিকড় ছাড়া অন্য কোথাও থেকে গাছে হাঁটা শুরু করাও অসম্ভব ছিল।
অবশেষে, রেন্ডারিং পাইপলাইনে অনেকগুলি অন-র্যাম্প ছিল পুরো কোড জুড়ে: জাভাস্ক্রিপ্ট দ্বারা ট্রিগার করা বাধ্যতামূলক লেআউট, ডকুমেন্ট লোডের সময় আংশিক আপডেট ট্রিগার করা, ইভেন্ট টার্গেটিংয়ের জন্য প্রস্তুত করার জন্য বাধ্যতামূলক আপডেট, ডিসপ্লে সিস্টেম দ্বারা অনুরোধ করা নির্ধারিত আপডেট, এবং বিশেষ API গুলি উন্মুক্ত শুধুমাত্র কোড পরীক্ষা করতে, কয়েকটি নাম দিতে। রেন্ডারিং পাইপলাইনে এমনকি কয়েকটি পুনরাবৃত্ত এবং পুনঃপ্রবেশকারী পথ ছিল (অর্থাৎ, এক পর্যায়ের শুরুতে অন্যটির মাঝখানে ঝাঁপ দেওয়া)। এই অন-র্যাম্পগুলির প্রত্যেকটির নিজস্ব স্বতন্ত্র আচরণ ছিল এবং কিছু ক্ষেত্রে রেন্ডারিংয়ের আউটপুট রেন্ডারিং আপডেটটি যে পদ্ধতিতে ট্রিগার করা হয়েছিল তার উপর নির্ভর করবে।
আমরা কি পরিবর্তন
ব্লিঙ্কএনজি অনেকগুলি উপ-প্রকল্পের সমন্বয়ে গঠিত, বড় এবং ছোট, সবকটিই পূর্বে বর্ণিত স্থাপত্যের ঘাটতি দূর করার লক্ষ্যে ভাগ করা। এই প্রকল্পগুলি রেন্ডারিং পাইপলাইনকে একটি প্রকৃত পাইপলাইন করার জন্য ডিজাইন করা কয়েকটি গাইডিং নীতি ভাগ করে:
- প্রবেশের অভিন্ন পয়েন্ট : আমাদের সর্বদা শুরুতে পাইপলাইনে প্রবেশ করা উচিত।
- কার্যকরী পর্যায় : প্রতিটি পর্যায়ে সু-সংজ্ঞায়িত ইনপুট এবং আউটপুট থাকা উচিত, এবং এর আচরণ কার্যকরী হওয়া উচিত, অর্থাৎ, নির্ধারক এবং পুনরাবৃত্তিযোগ্য, এবং আউটপুটগুলি শুধুমাত্র সংজ্ঞায়িত ইনপুটগুলির উপর নির্ভর করা উচিত।
- ধ্রুবক ইনপুট : স্টেজ চলাকালীন যেকোনো পর্যায়ের ইনপুট কার্যকরভাবে ধ্রুবক হওয়া উচিত।
- অপরিবর্তনীয় আউটপুট : একটি পর্যায় শেষ হয়ে গেলে, রেন্ডারিং আপডেটের বাকি অংশের জন্য এর আউটপুট অপরিবর্তনীয় হওয়া উচিত।
- চেকপয়েন্ট সামঞ্জস্যতা : প্রতিটি পর্যায়ের শেষে, এই পর্যন্ত উত্পাদিত রেন্ডারিং ডেটা একটি স্ব-সামঞ্জস্যপূর্ণ অবস্থায় থাকা উচিত।
- কাজের অনুলিপি : শুধুমাত্র একবার প্রতিটি জিনিস গণনা করুন।
ব্লিঙ্কএনজি সাব-প্রকল্পগুলির একটি সম্পূর্ণ তালিকা ক্লান্তিকর পড়ার জন্য তৈরি করবে, তবে নিম্নলিখিত কয়েকটি বিশেষ ফলাফল রয়েছে।
নথির জীবনচক্র
ডকুমেন্টলাইফসাইকেল ক্লাস রেন্ডারিং পাইপলাইনের মাধ্যমে আমাদের অগ্রগতির ট্র্যাক রাখে। এটি আমাদের প্রাথমিক চেকগুলি করতে দেয় যা পূর্বে তালিকাভুক্ত ইনভেরিয়েন্টগুলিকে প্রয়োগ করে, যেমন:
- যদি আমরা একটি ComputedStyle সম্পত্তি পরিবর্তন করি, তাহলে নথির জীবনচক্র অবশ্যই
kInStyleRecalcহতে হবে। - যদি DocumentLifecycle অবস্থা
kStyleCleanবা তার পরে হয়, তাহলেNeedsStyleRecalc()যেকোন সংযুক্ত নোডের জন্য মিথ্যা ফেরত দিতে হবে। - পেইন্ট লাইফসাইকেল পর্বে প্রবেশ করার সময়, জীবনচক্রের অবস্থা অবশ্যই
kPrePaintCleanহতে হবে।
ব্লিঙ্কএনজি বাস্তবায়নের সময়, আমরা পদ্ধতিগতভাবে কোড পাথগুলিকে সরিয়ে দিয়েছি যা এই ইনভেরিয়েন্টগুলিকে লঙ্ঘন করেছিল, এবং আমরা যাতে পশ্চাদপসরণ না করি তা নিশ্চিত করার জন্য পুরো কোড জুড়ে আরও অনেক দাবি ছিটিয়ে দিয়েছি।
আপনি যদি কখনও নিম্ন-স্তরের রেন্ডারিং কোডের দিকে তাকিয়ে খরগোশের গর্তে নেমে থাকেন তবে আপনি নিজেকে জিজ্ঞাসা করতে পারেন, "আমি এখানে কীভাবে এলাম?" পূর্বে উল্লিখিত হিসাবে, রেন্ডারিং পাইপলাইনে প্রবেশের বিভিন্ন পয়েন্ট রয়েছে। পূর্বে, এর মধ্যে পুনরাবৃত্ত এবং পুনঃপ্রবেশকারী কল পাথ এবং সেই স্থানগুলি অন্তর্ভুক্ত ছিল যেখানে আমরা শুরু থেকে শুরু করার পরিবর্তে একটি মধ্যবর্তী পর্যায়ে পাইপলাইনে প্রবেশ করেছি। ব্লিঙ্কএনজি চলাকালীন, আমরা এই কল পাথগুলি বিশ্লেষণ করেছি এবং নির্ধারণ করেছি যে সেগুলি দুটি মৌলিক পরিস্থিতিতে হ্রাসযোগ্য:
- সমস্ত রেন্ডারিং ডেটা আপডেট করা দরকার—উদাহরণস্বরূপ, প্রদর্শনের জন্য নতুন পিক্সেল তৈরি করার সময় বা ইভেন্ট টার্গেটিংয়ের জন্য একটি হিট পরীক্ষা করার সময়।
- আমাদের একটি নির্দিষ্ট প্রশ্নের জন্য একটি আপ-টু-ডেট মান প্রয়োজন যা সমস্ত রেন্ডারিং ডেটা আপডেট না করেই উত্তর দেওয়া যেতে পারে। এর মধ্যে বেশিরভাগ জাভাস্ক্রিপ্ট কোয়েরি রয়েছে, উদাহরণস্বরূপ,
node.offsetTop।
রেন্ডারিং পাইপলাইনে এখন প্রবেশের মাত্র দুটি পয়েন্ট রয়েছে, এই দুটি পরিস্থিতির সাথে সঙ্গতিপূর্ণ। পুনঃপ্রবেশকারী কোড পাথগুলি সরানো হয়েছে বা রিফ্যাক্টর করা হয়েছে, এবং একটি মধ্যবর্তী পর্যায়ে শুরু করে পাইপলাইনে প্রবেশ করা আর সম্ভব নয়। এটি ঠিক কখন এবং কীভাবে রেন্ডারিং আপডেটগুলি ঘটবে তা ঘিরে অনেক রহস্য দূর করেছে, সিস্টেমের আচরণ সম্পর্কে যুক্তি করা আরও সহজ করে তুলেছে।
পাইপলাইনিং স্টাইল, লেআউট এবং প্রি-পেইন্ট
সমষ্টিগতভাবে, পেইন্টের আগে রেন্ডারিং পর্যায়গুলি নিম্নলিখিতগুলির জন্য দায়ী:
- DOM নোডের জন্য চূড়ান্ত শৈলী বৈশিষ্ট্য গণনা করতে স্টাইল ক্যাসকেড অ্যালগরিদম চালানো হচ্ছে।
- ডকুমেন্টের বক্স অনুক্রমের প্রতিনিধিত্বকারী লেআউট ট্রি তৈরি করা হচ্ছে।
- সমস্ত বাক্সের জন্য আকার এবং অবস্থানের তথ্য নির্ধারণ করা।
- পেইন্টিংয়ের জন্য পুরো পিক্সেল সীমানায় সাব-পিক্সেল জ্যামিতি বৃত্তাকার বা স্ন্যাপ করা।
- সংমিশ্রিত স্তরগুলির বৈশিষ্ট্য নির্ধারণ করা (অ্যাফাইন ট্রান্সফর্মেশন, ফিল্টার, অপাসিটি, বা অন্য কিছু যা GPU ত্বরিত হতে পারে)।
- পূর্ববর্তী পেইন্ট পর্যায় থেকে কি বিষয়বস্তু পরিবর্তিত হয়েছে তা নির্ধারণ করা এবং আঁকা বা পুনরায় রং করা প্রয়োজন (পেইন্ট অবৈধকরণ)।
এই তালিকাটি পরিবর্তিত হয়নি, কিন্তু BlinkNG এর আগে এই কাজটির বেশিরভাগই অ্যাডহক উপায়ে করা হয়েছিল, অনেকগুলি সদৃশ কার্যকারিতা এবং অন্তর্নির্মিত অদক্ষতা সহ একাধিক রেন্ডারিং পর্যায়ে ছড়িয়ে পড়েছিল। উদাহরণ স্বরূপ, স্টাইল ফেজ সর্বদাই প্রাথমিকভাবে নোডের জন্য চূড়ান্ত শৈলী বৈশিষ্ট্য গণনার জন্য দায়ী, কিন্তু কিছু বিশেষ ক্ষেত্রে আমরা শৈলী পর্ব সম্পূর্ণ না হওয়া পর্যন্ত চূড়ান্ত শৈলী সম্পত্তি মান নির্ধারণ করিনি। রেন্ডারিং প্রক্রিয়ায় কোন আনুষ্ঠানিক বা প্রয়োগযোগ্য বিন্দু ছিল না যেখানে আমরা নিশ্চিতভাবে বলতে পারি যে শৈলী তথ্য সম্পূর্ণ এবং অপরিবর্তনীয় ছিল।
প্রি-ব্লিঙ্কএনজি ঝামেলার আরেকটি ভালো উদাহরণ হল পেইন্ট অবৈধতা। পূর্বে, পেইন্ট অকার্যকরতা পেইন্ট পর্যন্ত সমস্ত রেন্ডারিং পর্যায় জুড়ে ছড়িয়ে পড়েছিল। শৈলী বা লেআউট কোড পরিবর্তন করার সময়, পেইন্ট অবৈধকরণ যুক্তিতে কী পরিবর্তন প্রয়োজন তা জানা কঠিন ছিল এবং একটি ভুল করা সহজ ছিল যার ফলে কম বা অতিরিক্ত-অবৈধকরণ বাগগুলি ঘটে। আপনি লেআউটএনজিতে উত্সর্গীকৃত এই সিরিজ থেকে নিবন্ধে পুরানো পেইন্ট অবৈধকরণ সিস্টেমের জটিলতা সম্পর্কে আরও পড়তে পারেন।
পেইন্টিংয়ের জন্য পুরো পিক্সেল সীমানায় সাবপিক্সেল লেআউট জ্যামিতি স্ন্যাপ করা একটি উদাহরণ যেখানে আমাদের একই কার্যকারিতার একাধিক বাস্তবায়ন ছিল এবং অনেক অপ্রয়োজনীয় কাজ করেছি। পেইন্ট সিস্টেমের দ্বারা ব্যবহৃত একটি পিক্সেল-স্ন্যাপিং কোড পাথ ছিল এবং যখনই আমাদের পেইন্ট কোডের বাইরে পিক্সেল-স্ন্যাপ করা স্থানাঙ্কগুলির এক-অফ, অন-দ্য-ফ্লাই গণনার প্রয়োজন হয় তখন একটি সম্পূর্ণ আলাদা কোড পাথ ব্যবহার করা হয়েছিল। বলা বাহুল্য, প্রতিটি বাস্তবায়নের নিজস্ব বাগ ছিল এবং তাদের ফলাফল সবসময় মেলে না। যেহেতু এই তথ্যের কোন ক্যাশিং ছিল না, সিস্টেমটি কখনও কখনও সঠিক একই গণনা বারবার সঞ্চালন করবে - কর্মক্ষমতার উপর আরেকটি চাপ।
এখানে কিছু উল্লেখযোগ্য প্রকল্প রয়েছে যা পেইন্ট করার পূর্বে রেন্ডারিং পর্যায়গুলির স্থাপত্যগত ঘাটতি দূর করেছে।
প্রজেক্ট স্কোয়াড: স্টাইল ফেজ পাইপলাইন করা
এই প্রকল্পটি শৈলী পর্যায়ে দুটি প্রধান ঘাটতি মোকাবেলা করেছে যা এটিকে পরিষ্কারভাবে পাইপলাইন করা থেকে বাধা দিয়েছে:
শৈলী পর্বের দুটি প্রাথমিক আউটপুট রয়েছে: ComputedStyle , যার মধ্যে DOM গাছের উপরে CSS ক্যাসকেড অ্যালগরিদম চালানোর ফলাফল রয়েছে; এবং LayoutObjects এর একটি গাছ, যা লেআউট পর্বের জন্য অপারেশনের ক্রম স্থাপন করে। ধারণাগতভাবে, লেআউট ট্রি তৈরি করার আগে ক্যাসকেড অ্যালগরিদম চালানো কঠোরভাবে ঘটতে হবে; কিন্তু পূর্বে, এই দুটি অপারেশন ইন্টারলিভড ছিল। প্রজেক্ট স্কোয়াড এই দুটিকে পৃথক, অনুক্রমিক পর্যায়ে বিভক্ত করতে সফল হয়েছে।
পূর্বে, ComputedStyle সবসময় স্টাইল রিকালকের সময় তার চূড়ান্ত মান পায়নি; কিছু পরিস্থিতি ছিল যেখানে ComputedStyle পরবর্তী পাইপলাইন পর্যায়ে আপডেট করা হয়েছিল। প্রজেক্ট স্কোয়াড সফলভাবে এই কোড পাথগুলিকে রিফ্যাক্টর করেছে, যাতে স্টাইল পর্বের পরে ComputedStyle কখনও পরিবর্তন করা হয় না।
লেআউটএনজি: লেআউট ফেজ পাইপলাইন করা
এই স্মারক প্রকল্প — রেন্ডারিংএনজি-এর অন্যতম ভিত্তি — লেআউট রেন্ডারিং পর্বের সম্পূর্ণ পুনর্লিখন ছিল। আমরা এখানে সম্পূর্ণ প্রকল্পের প্রতি সুবিচার করব না, তবে সামগ্রিক BlinkNG প্রকল্পের জন্য কয়েকটি উল্লেখযোগ্য দিক রয়েছে:
- পূর্বে, লেআউট ফেজ শৈলী ফেজ দ্বারা তৈরি
LayoutObjectএর একটি ট্রি পেয়েছিল এবং আকার এবং অবস্থানের তথ্য সহ ট্রিটিকে টীকা করত। সুতরাং, আউটপুট থেকে ইনপুটগুলির কোনও পরিষ্কার বিচ্ছেদ ছিল না। LayoutNG ফ্র্যাগমেন্ট ট্রি প্রবর্তন করেছে, যা লেআউটের প্রাথমিক, শুধুমাত্র-পঠনযোগ্য আউটপুট এবং পরবর্তী রেন্ডারিং পর্যায়ে প্রাথমিক ইনপুট হিসাবে কাজ করে। - LayoutNG কনটেইনমেন্ট প্রপার্টিটিকে লেআউটে নিয়ে এসেছে: একটি প্রদত্ত
LayoutObjectএর আকার এবং অবস্থান গণনা করার সময়, আমরা আর সেই বস্তুর মূল উপবৃক্ষের বাইরে তাকাই না। একটি প্রদত্ত বস্তুর জন্য লেআউট আপডেট করার জন্য প্রয়োজনীয় সমস্ত তথ্য আগে থেকে গণনা করা হয় এবং অ্যালগরিদমে শুধুমাত্র পঠনযোগ্য ইনপুট হিসাবে প্রদান করা হয়। - পূর্বে, এজ কেস ছিল যেখানে লেআউট অ্যালগরিদম কঠোরভাবে কার্যকরী ছিল না: অ্যালগরিদমের ফলাফল সবচেয়ে সাম্প্রতিক পূর্ববর্তী লেআউট আপডেটের উপর নির্ভর করে। লেআউটএনজি সেই মামলাগুলিকে সরিয়ে দিয়েছে।
প্রাক পেইন্ট পর্যায়
পূর্বে, কোন আনুষ্ঠানিক প্রাক-পেইন্ট রেন্ডারিং ফেজ ছিল না, শুধুমাত্র পোস্ট-লেআউট অপারেশনগুলির একটি গ্র্যাব ব্যাগ। প্রি-পেইন্ট পর্যায়টি এই স্বীকৃতির কারণে বেড়েছে যে কয়েকটি সম্পর্কিত ফাংশন রয়েছে যা লেআউট সম্পূর্ণ হওয়ার পরে লেআউট ট্রির একটি পদ্ধতিগত ট্রাভার্সাল হিসাবে সর্বোত্তমভাবে প্রয়োগ করা যেতে পারে; সবচেয়ে গুরুত্বপূর্ণভাবে:
- পেইন্ট অকার্যকরকরণ ইস্যু করা : লেআউট চলাকালীন সঠিকভাবে পেইন্ট অবৈধকরণ করা খুবই কঠিন, যখন আমাদের কাছে অসম্পূর্ণ তথ্য থাকে। এটি সঠিক হওয়া অনেক সহজ, এবং এটি খুব দক্ষ হতে পারে, যদি এটি দুটি স্বতন্ত্র প্রক্রিয়ায় বিভক্ত হয়: শৈলী এবং বিন্যাসের সময়, বিষয়বস্তুকে একটি সাধারণ বুলিয়ান পতাকা দিয়ে চিহ্নিত করা যেতে পারে "সম্ভবত পেইন্ট অবৈধকরণের প্রয়োজন।" প্রি-পেইন্ট ট্রি ওয়াক করার সময়, আমরা এই পতাকাগুলি পরীক্ষা করি এবং প্রয়োজনে অবৈধতা জারি করি।
- পেইন্ট প্রোপার্টি ট্রি তৈরি করা : একটি প্রক্রিয়া আরও বিশদে বর্ণনা করা হয়েছে।
- পিক্সেল-স্ন্যাপড পেইন্ট অবস্থানগুলি কম্পিউটিং এবং রেকর্ডিং : রেকর্ড করা ফলাফলগুলি পেইন্ট ফেজ দ্বারা ব্যবহার করা যেতে পারে, এবং যেকোন ডাউনস্ট্রীম কোড দ্বারাও ব্যবহার করা যেতে পারে যা তাদের প্রয়োজন, কোন অপ্রয়োজনীয় গণনা ছাড়াই৷
সম্পত্তি গাছ: সামঞ্জস্যপূর্ণ জ্যামিতি
স্ক্রলিংয়ের জটিলতা মোকাবেলা করার জন্য রেন্ডারিংএনজি-তে প্রপার্টি ট্রিগুলি প্রথম দিকে চালু করা হয়েছিল, যা ওয়েবে অন্যান্য সমস্ত ধরণের ভিজ্যুয়াল এফেক্টের চেয়ে আলাদা কাঠামো রয়েছে। সম্পত্তি গাছের আগে, ক্রোমিয়ামের কম্পোজিটর একটি একক "স্তর" শ্রেণীবিন্যাস ব্যবহার করে সংমিশ্রিত বিষয়বস্তুর জ্যামিতিক সম্পর্কের প্রতিনিধিত্ব করে, কিন্তু এটি দ্রুত বিচ্ছিন্ন হয়ে যায় কারণ বৈশিষ্ট্যগুলির সম্পূর্ণ জটিলতা যেমন অবস্থান: স্থির স্পষ্ট হয়ে ওঠে। স্তর শ্রেণিবিন্যাস একটি স্তরের "স্ক্রোল প্যারেন্ট" বা "ক্লিপ প্যারেন্ট" নির্দেশ করে অতিরিক্ত অ-স্থানীয় পয়েন্টার বৃদ্ধি করেছে এবং অনেক আগেই কোডটি বোঝা খুব কঠিন ছিল।
প্রপার্টি ট্রিগুলি অন্যান্য সমস্ত ভিজ্যুয়াল এফেক্ট থেকে আলাদাভাবে বিষয়বস্তুর ওভারফ্লো স্ক্রোল এবং ক্লিপ দিকগুলিকে প্রতিনিধিত্ব করে এটি ঠিক করেছে। এটি ওয়েবসাইটগুলির সত্যিকারের ভিজ্যুয়াল এবং স্ক্রোলিং কাঠামোকে সঠিকভাবে মডেল করা সম্ভব করেছে। এর পরে, আমাদের "সমস্ত" করতে হয়েছিল প্রপার্টি ট্রিগুলির উপরে অ্যালগরিদমগুলি প্রয়োগ করা, যেমন সংমিশ্রিত স্তরগুলির স্ক্রিন-স্পেস রূপান্তর, বা কোন স্তরগুলি স্ক্রোল করা হয়েছে এবং কোনটি হয়নি তা নির্ধারণ করা।
আসলে, আমরা শীঘ্রই লক্ষ্য করেছি যে কোডটিতে আরও অনেক জায়গা ছিল যেখানে একই ধরনের জ্যামিতিক প্রশ্ন উত্থাপিত হয়েছিল। ( কি ডাটা স্ট্রাকচার পোস্টে আরও সম্পূর্ণ তালিকা রয়েছে।) তাদের মধ্যে বেশ কয়েকটিতে কম্পোজিটর কোডের একই জিনিসের নকল বাস্তবায়ন ছিল; সকলেরই বাগগুলির একটি ভিন্ন উপসেট ছিল; এবং তাদের কেউই সঠিকভাবে সঠিক ওয়েবসাইট কাঠামো মডেল করেনি। সমাধানটি তখন পরিষ্কার হয়ে গেল: সমস্ত জ্যামিতি অ্যালগরিদমকে এক জায়গায় কেন্দ্রীভূত করুন এবং এটি ব্যবহার করার জন্য সমস্ত কোড রিফ্যাক্টর করুন।
এই অ্যালগরিদমগুলি ঘুরেফিরে সমস্ত সম্পত্তি গাছের উপর নির্ভর করে, এই কারণেই সম্পত্তি গাছগুলি হল একটি মূল ডেটা স্ট্রাকচার-অর্থাৎ, রেন্ডারিংএনজি-এর পাইপলাইনে ব্যবহৃত একটি। তাই কেন্দ্রীভূত জ্যামিতি কোডের এই লক্ষ্য অর্জনের জন্য, আমাদের প্রোপার্টি গাছের ধারণাটি পাইপলাইনে অনেক আগে প্রবর্তন করতে হবে-প্রি-পেইন্টে-এবং সেগুলি কার্যকর করার আগে প্রি-পেইন্ট চালানোর জন্য এখন তাদের উপর নির্ভরশীল সমস্ত API পরিবর্তন করতে হবে। .
এই গল্পটি ব্লিঙ্কএনজি রিফ্যাক্টরিং প্যাটার্নের আরেকটি দিক: মূল গণনাগুলি সনাক্ত করুন, তাদের নকল এড়াতে রিফ্যাক্টর এবং সু-সংজ্ঞায়িত পাইপলাইন স্তরগুলি তৈরি করুন যা তাদের খাওয়ানোর ডেটা কাঠামো তৈরি করে। আমরা যখন সমস্ত প্রয়োজনীয় তথ্য উপলব্ধ থাকে ঠিক তখনই সম্পত্তি গাছের গণনা করি; এবং আমরা নিশ্চিত করি যে পরবর্তীতে রেন্ডারিং পর্যায় চলাকালীন সম্পত্তি গাছগুলি পরিবর্তন করা যাবে না।
পেইন্টের পরে কম্পোজিট: পাইপলাইন পেইন্ট এবং কম্পোজিটিং
লেয়ারাইজেশন হল কোন DOM বিষয়বস্তু তার নিজস্ব সংমিশ্রিত স্তরে যায় তা নির্ধারণ করার প্রক্রিয়া (যা ঘুরে, একটি GPU টেক্সচারের প্রতিনিধিত্ব করে)। রেন্ডারিংএনজি-এর আগে, লেয়ারাইজেশন পেইন্টের আগে চলত, পরে নয় (বর্তমান পাইপলাইনের জন্য এখানে দেখুন-ক্রমের পরিবর্তন লক্ষ্য করুন)। আমরা প্রথমে সিদ্ধান্ত নেব যে DOM-এর কোন অংশগুলি কোন সংমিশ্রিত স্তরে যাবে, এবং শুধুমাত্র তারপর সেই টেক্সচারগুলির জন্য প্রদর্শন তালিকা আঁকব। স্বাভাবিকভাবেই, ডিওএম উপাদানগুলি অ্যানিমেটিং বা স্ক্রোলিং করছে, বা 3D রূপান্তর করেছে এবং কোন উপাদানগুলির উপরে আঁকা হয়েছে তার উপর সিদ্ধান্তগুলি নির্ভর করে৷
এটি বড় সমস্যা সৃষ্টি করেছে, কারণ এটির কমবেশি প্রয়োজন যে কোডে সার্কুলার নির্ভরতা ছিল, যা একটি রেন্ডারিং পাইপলাইনের জন্য একটি বড় সমস্যা। কেন একটি উদাহরণ মাধ্যমে দেখা যাক. ধরুন আমাদের পেইন্টকে অবৈধ করতে হবে (অর্থাৎ আমাদের ডিসপ্লে তালিকা পুনরায় আঁকতে হবে এবং তারপরে আবার রাস্টার করতে হবে)। অকার্যকর করার প্রয়োজনীয়তা DOM-এ পরিবর্তন, অথবা পরিবর্তিত স্টাইল বা লেআউট থেকে আসতে পারে। তবে অবশ্যই, আমরা শুধুমাত্র সেই অংশগুলিকে বাতিল করতে চাই যা আসলে পরিবর্তিত হয়েছে। এর অর্থ হল কোন সংমিশ্রিত স্তরগুলি প্রভাবিত হয়েছে তা খুঁজে বের করা, এবং তারপর সেই স্তরগুলির জন্য অংশ বা সমস্ত প্রদর্শন তালিকা বাতিল করা।
এর মানে হল যে অবৈধতা নির্ভর করে DOM, শৈলী, বিন্যাস এবং অতীত স্তরকরণ সিদ্ধান্তের উপর (অতীত: পূর্ববর্তী রেন্ডার করা ফ্রেমের জন্য অর্থ)। কিন্তু বর্তমান স্তরায়ন সেই সমস্ত জিনিসের উপরও নির্ভর করে। এবং যেহেতু আমাদের কাছে সমস্ত স্তরকরণ ডেটার দুটি কপি ছিল না, তাই অতীত এবং ভবিষ্যতের স্তরকরণ সিদ্ধান্তের মধ্যে পার্থক্য বলা কঠিন ছিল। তাই আমরা বৃত্তাকার যুক্তি ছিল যে কোড প্রচুর সঙ্গে শেষ. এটি কখনও কখনও অযৌক্তিক বা ভুল কোড বা এমনকি ক্র্যাশ বা সুরক্ষা সমস্যাগুলির দিকে পরিচালিত করে, যদি আমরা খুব সতর্ক না হই।
এই পরিস্থিতি মোকাবেলা করার জন্য, প্রথম দিকে আমরা DisableCompositingQueryAsserts অবজেক্টের ধারণাটি চালু করেছি। বেশিরভাগ সময়, যদি কোড অতীতের লেয়ারাইজেশন সিদ্ধান্তগুলি জিজ্ঞাসা করার চেষ্টা করে, তবে এটি একটি দাবী ব্যর্থতার কারণ হবে এবং ব্রাউজারটি ডিবাগ মোডে থাকলে তা ক্র্যাশ করবে। এটি আমাদের নতুন বাগ প্রবর্তন এড়াতে সাহায্য করেছে৷ এবং প্রতিটি ক্ষেত্রে যেখানে কোডটি বৈধভাবে অতীতের লেয়ারাইজেশন সিদ্ধান্তগুলি জিজ্ঞাসা করার জন্য প্রয়োজন, আমরা একটি DisableCompositingQueryAsserts অবজেক্ট বরাদ্দ করে অনুমতি দেওয়ার জন্য কোড রাখি।
আমাদের পরিকল্পনা ছিল, সময়ের সাথে সাথে, সমস্ত কল সাইটগুলি DisableCompositingQueryAssert অবজেক্ট থেকে পরিত্রাণ পেতে, এবং তারপর কোডটিকে নিরাপদ এবং সঠিক ঘোষণা করা। কিন্তু আমরা যা আবিষ্কার করেছি তা হল যে পেইন্টের আগে যতক্ষণ লেয়ারাইজেশন ঘটেছিল ততক্ষণ পর্যন্ত অনেকগুলি কল অপসারণ করা মূলত অসম্ভব ছিল। (আমরা অবশেষে খুব সম্প্রতি এটিকে অপসারণ করতে সক্ষম হয়েছি!) কম্পোজিট আফটার পেইন্ট প্রকল্পের জন্য এটিই প্রথম কারণ আবিষ্কার করা হয়েছিল। আমরা যা শিখেছি তা হল, অপারেশনের জন্য আপনার কাছে একটি সু-সংজ্ঞায়িত পাইপলাইন ফেজ থাকলেও, যদি এটি পাইপলাইনের ভুল জায়গায় থাকে তবে আপনি অবশেষে আটকে যাবেন।
কম্পোজিট আফটার পেইন্ট প্রজেক্টের দ্বিতীয় কারণ ছিল ফান্ডামেন্টাল কম্পোজিটিং বাগ। এই বাগটি বলার একটি উপায় হল যে DOM উপাদানগুলি ওয়েব পৃষ্ঠার বিষয়বস্তুর জন্য একটি দক্ষ বা সম্পূর্ণ স্তরায়ন প্রকল্পের একটি ভাল 1:1 উপস্থাপনা নয়। এবং যেহেতু কম্পোজিটিং পেইন্টের আগে ছিল, তাই এটি কমবেশি স্বভাবতই DOM উপাদানের উপর নির্ভর করে, প্রদর্শন তালিকা বা সম্পত্তি গাছ নয়। আমরা যে কারণে প্রপার্টি ট্রি প্রবর্তন করেছি তার সাথে এটি খুবই মিল, এবং ঠিক যেমন প্রপার্টি ট্রির সাথে, আপনি যদি সঠিক পাইপলাইন ফেজটি বের করেন, সঠিক সময়ে এটি চালান এবং সঠিক কী ডেটা স্ট্রাকচার প্রদান করেন তাহলে সমাধানটি সরাসরি বেরিয়ে আসে। এবং সম্পত্তি গাছের মতো, এটি গ্যারান্টি দেওয়ার একটি ভাল সুযোগ ছিল যে একবার পেইন্ট ফেজ সম্পূর্ণ হয়ে গেলে, এর আউটপুট পরবর্তী সমস্ত পাইপলাইনের পর্যায়গুলির জন্য অপরিবর্তনীয়।
সুবিধা
আপনি যেমন দেখেছেন, একটি সু-সংজ্ঞায়িত রেন্ডারিং পাইপলাইন প্রচুর দীর্ঘমেয়াদী সুবিধা দেয়। আপনি যা ভাবতে পারেন তার চেয়েও বেশি কিছু আছে:
- ব্যাপকভাবে উন্নত নির্ভরযোগ্যতা : এটি বেশ সহজবোধ্য। ভালভাবে সংজ্ঞায়িত এবং বোধগম্য ইন্টারফেস সহ ক্লিনার কোড বোঝা, লেখা এবং পরীক্ষা করা সহজ। এটি আরও নির্ভরযোগ্য করে তোলে। এটি কম ক্র্যাশ এবং কম ব্যবহারের পরে-মুক্ত বাগ সহ কোডটিকে আরও নিরাপদ এবং আরও স্থিতিশীল করে তোলে।
- বর্ধিত পরীক্ষার কভারেজ : BlinkNG এর কোর্সে, আমরা আমাদের স্যুটে অনেক নতুন পরীক্ষা যোগ করেছি। এর মধ্যে রয়েছে ইউনিট পরীক্ষা যা ইন্টার্নালের ফোকাসড ভেরিফিকেশন প্রদান করে; রিগ্রেশন পরীক্ষা যা আমাদেরকে আমাদের ঠিক করা পুরানো বাগগুলিকে পুনরায় প্রবর্তন করতে বাধা দেয় (এত বেশি!); এবং জনসাধারণের জন্য প্রচুর সংযোজন, সমষ্টিগতভাবে রক্ষণাবেক্ষণ করা ওয়েব প্ল্যাটফর্ম টেস্ট স্যুট , যা সমস্ত ব্রাউজার ওয়েব মানগুলির সাথে সামঞ্জস্য পরিমাপ করতে ব্যবহার করে৷
- প্রসারিত করা সহজ : যদি একটি সিস্টেমকে পরিষ্কার উপাদানগুলিতে বিভক্ত করা হয়, তবে বর্তমানের উপর অগ্রগতি করার জন্য বিশদ স্তরে অন্যান্য উপাদানগুলি বোঝার প্রয়োজন নেই। এটি প্রত্যেকের জন্য গভীর বিশেষজ্ঞ না হয়ে রেন্ডারিং কোডে মান যোগ করা সহজ করে তোলে এবং এটি সমগ্র সিস্টেমের আচরণ সম্পর্কে যুক্তি করাও সহজ করে তোলে।
- কর্মক্ষমতা : স্প্যাগেটি কোডে লেখা অ্যালগরিদমগুলি অপ্টিমাইজ করা যথেষ্ট কঠিন, তবে এমন একটি পাইপলাইন ছাড়া সর্বজনীন থ্রেডেড স্ক্রোলিং এবং অ্যানিমেশন বা সাইট আইসোলেশনের প্রক্রিয়া এবং থ্রেডের মতো আরও বড় জিনিসগুলি অর্জন করা প্রায় অসম্ভব। সমান্তরালতা আমাদের কার্যক্ষমতাকে অসাধারণভাবে উন্নত করতে সাহায্য করতে পারে, তবে এটি অত্যন্ত জটিলও।
- ফলন এবং নিয়ন্ত্রণ : ব্লিঙ্কএনজির দ্বারা সম্ভব করা বেশ কিছু নতুন বৈশিষ্ট্য রয়েছে যা নতুন এবং অভিনব উপায়ে পাইপলাইন ব্যবহার করে। উদাহরণস্বরূপ, যদি আমরা বাজেটের মেয়াদ শেষ না হওয়া পর্যন্ত শুধুমাত্র রেন্ডারিং পাইপলাইন চালাতে চাই? অথবা এই মুহূর্তে ব্যবহারকারীর সাথে প্রাসঙ্গিক নয় বলে পরিচিত সাবট্রির জন্য রেন্ডারিং এড়িয়ে যাবেন? বিষয়বস্তু-দৃশ্যমানতা CSS প্রপার্টি এটিই সক্ষম করে। কোন কম্পোনেন্টের স্টাইল তার লেআউটের উপর নির্ভর করে? যে কন্টেইনার প্রশ্ন .
কেস স্টাডি: কন্টেইনার প্রশ্ন
কন্টেইনার কোয়েরি হল একটি উচ্চ প্রত্যাশিত আসন্ন ওয়েব প্ল্যাটফর্ম বৈশিষ্ট্য (এটি বছরের পর বছর ধরে CSS ডেভেলপারদের কাছ থেকে এক নম্বর সর্বাধিক অনুরোধ করা বৈশিষ্ট্য)। যদি এটি এত দুর্দান্ত হয় তবে কেন এটি এখনও বিদ্যমান নেই? কারণ হল যে কন্টেইনার ক্যোয়ারী বাস্তবায়নের জন্য শৈলী এবং লেআউট কোডের মধ্যে সম্পর্কের খুব সাবধানে বোঝার এবং নিয়ন্ত্রণ প্রয়োজন। এর একটি ঘনিষ্ঠ কটাক্ষপাত করা যাক.
একটি ধারক ক্যোয়ারী একটি উপাদানে প্রযোজ্য শৈলীগুলিকে পূর্বপুরুষের বিন্যস্ত আকারের উপর নির্ভর করতে দেয়৷ যেহেতু লেআউটের সময় লেআউট সাইজ গণনা করা হয়, তার মানে লেআউটের পরে আমাদের স্টাইল রিকালক চালাতে হবে; কিন্তু শৈলী recalc লেআউট আগে রান ! এই মুরগি-এবং-ডিম প্যারাডক্সটি সম্পূর্ণ কারণ কেন আমরা BlinkNG এর আগে কন্টেইনার প্রশ্নগুলি বাস্তবায়ন করতে পারিনি।
আমরা কিভাবে এটি সমাধান করতে পারি? এটি কি পিছন দিকের পাইপলাইন নির্ভরতা নয়, অর্থাৎ একই সমস্যা যা কম্পোজিট আফটার পেইন্টের মতো প্রকল্পগুলি সমাধান করেছে? আরও খারাপ, যদি নতুন শৈলী পূর্বপুরুষের আকার পরিবর্তন করে? এটি কি কখনও কখনও একটি অসীম লুপের দিকে পরিচালিত করবে না?
নীতিগতভাবে, বৃত্তাকার নির্ভরতা Cont CSS প্রপার্টি ব্যবহার করে সমাধান করা যেতে পারে, যা একটি উপাদানের বাইরে রেন্ডারিংকে সেই উপাদানের সাবট্রির মধ্যে রেন্ডারিংয়ের উপর নির্ভর না করার অনুমতি দেয়। এর মানে হল যে একটি ধারক দ্বারা প্রয়োগ করা নতুন শৈলীগুলি কন্টেইনারের আকারকে প্রভাবিত করতে পারে না, কারণ কন্টেইনার কোয়েরির জন্য কন্টেনমেন্ট প্রয়োজন ।
কিন্তু প্রকৃতপক্ষে, এটি যথেষ্ট ছিল না, এবং শুধুমাত্র আকারের কন্টেনমেন্টের চেয়ে একটি দুর্বল ধরনের কন্টেনমেন্ট প্রবর্তন করা প্রয়োজন ছিল। এর কারণ হল একটি কন্টেইনার কোয়েরি কন্টেইনার তার ইনলাইন মাত্রার উপর ভিত্তি করে শুধুমাত্র একটি দিকে (সাধারণত ব্লক) আকার পরিবর্তন করতে সক্ষম হওয়া সাধারণ। তাই ইনলাইন-আকার কন্টেনমেন্টের ধারণা যোগ করা হয়েছিল। কিন্তু আপনি সেই বিভাগে খুব দীর্ঘ নোট থেকে দেখতে পাচ্ছেন, ইনলাইন আকারের কন্টেনমেন্ট সম্ভব হলে এটি দীর্ঘ সময়ের জন্য মোটেই পরিষ্কার ছিল না।
বিমূর্ত স্পেক ভাষায় কন্টেনমেন্ট বর্ণনা করা এক জিনিস, এবং এটি সঠিকভাবে বাস্তবায়ন করা অন্য জিনিস। স্মরণ করুন যে ব্লিঙ্কএনজি-এর লক্ষ্যগুলির মধ্যে একটি ছিল ট্রি ওয়াকগুলিতে কন্টেনমেন্ট নীতি আনা যা রেন্ডারিংয়ের প্রধান যুক্তি গঠন করে: একটি সাবট্রি অতিক্রম করার সময়, সাবট্রির বাইরে থেকে কোনও তথ্যের প্রয়োজন হবে না। যেহেতু এটি ঘটে (ভাল, এটি ঠিক একটি দুর্ঘটনা ছিল না), রেন্ডারিং কোডটি কন্টেনমেন্ট নীতি মেনে চললে এটি CSS কন্টেনমেন্ট বাস্তবায়ন করা অনেক পরিষ্কার এবং সহজ।
ভবিষ্যত: অফ-মেইন-থ্রেড কম্পোজিটিং … এবং তার পরেও!
এখানে দেখানো রেন্ডারিং পাইপলাইনটি আসলে বর্তমান রেন্ডারিংএনজি বাস্তবায়নের থেকে কিছুটা এগিয়ে। এটি লেয়ারাইজেশনকে প্রধান থ্রেডের বাইরে বলে দেখায়, যেখানে বর্তমানে এটি এখনও মূল থ্রেডে রয়েছে। যাইহোক, এটি করার আগে এটি শুধুমাত্র সময়ের ব্যাপার, এখন যেহেতু কম্পোজিট আফটার পেইন্ট পাঠানো হয়েছে এবং লেয়ারাইজেশন পেইন্টের পরে।
কেন এটি গুরুত্বপূর্ণ তা বোঝার জন্য, এবং এটি অন্য কোথায় নিয়ে যেতে পারে, আমাদেরকে কিছুটা উচ্চ সুবিধার পয়েন্ট থেকে রেন্ডারিং ইঞ্জিনের আর্কিটেকচার বিবেচনা করতে হবে। Chromium-এর কর্মক্ষমতা উন্নত করার জন্য সবচেয়ে টেকসই বাধাগুলির মধ্যে একটি হল সহজ সত্য যে রেন্ডারারের প্রধান থ্রেডটি প্রধান অ্যাপ্লিকেশন লজিক (অর্থাৎ, স্ক্রিপ্ট চলমান) এবং রেন্ডারিংয়ের বড় অংশ উভয়ই পরিচালনা করে। ফলস্বরূপ, প্রধান থ্রেডটি প্রায়শই কাজের সাথে পরিপূর্ণ হয় এবং প্রধান থ্রেডের ভিড় প্রায়ই পুরো ব্রাউজারে বাধা হয়ে দাঁড়ায়।
ভাল খবর এটা এই ভাবে হতে হবে না যে! ক্রোমিয়ামের আর্কিটেকচারের এই দিকটি কেএইচটিএমএল দিনগুলিতে ফিরে আসে, যখন একক-থ্রেডেড এক্সিকিউশন ছিল প্রভাবশালী প্রোগ্রামিং মডেল। যখন মাল্টি-কোর প্রসেসরগুলি ভোক্তা-গ্রেড ডিভাইসগুলিতে সাধারণ হয়ে ওঠে, তখন একক-থ্রেডেড ধারণাটি ব্লিঙ্কে (আগে ওয়েবকিট) পুঙ্খানুপুঙ্খভাবে বেক করা হয়েছিল। আমরা দীর্ঘদিন ধরে রেন্ডারিং ইঞ্জিনে আরও থ্রেডিং চালু করতে চেয়েছিলাম, কিন্তু পুরানো সিস্টেমে এটি অসম্ভব ছিল। রেন্ডারিং এনজির অন্যতম প্রধান উদ্দেশ্য ছিল এই গর্ত থেকে নিজেদের খনন করা এবং রেন্ডারিং কাজকে আংশিক বা সম্পূর্ণভাবে অন্য থ্রেডে (বা থ্রেড) নিয়ে যাওয়া সম্ভব করে তোলা।
এখন যে BlinkNG সমাপ্তির কাছাকাছি, আমরা ইতিমধ্যে এই এলাকা অন্বেষণ শুরু করছি; নন-ব্লকিং কমিট হল রেন্ডারারের থ্রেডিং মডেল পরিবর্তন করার প্রথম অভিযান। কম্পোজিটর কমিট (বা শুধু কমিট ) হল প্রধান থ্রেড এবং কম্পোজিটর থ্রেডের মধ্যে একটি সিঙ্ক্রোনাইজেশন ধাপ। কমিট করার সময়, আমরা মূল থ্রেডে উত্পাদিত রেন্ডারিং ডেটার অনুলিপি তৈরি করি, যা কম্পোজিটর থ্রেডে চলমান ডাউনস্ট্রিম কম্পোজিটিং কোড দ্বারা ব্যবহার করা হবে। যখন এই সিঙ্ক্রোনাইজেশনটি ঘটছে, কম্পোজিটর থ্রেডে কপি করার কোড চলাকালীন মূল থ্রেড এক্সিকিউশন বন্ধ হয়ে গেছে। কম্পোজিটর থ্রেড এটি অনুলিপি করার সময় মূল থ্রেডটি তার রেন্ডারিং ডেটা পরিবর্তন করে না তা নিশ্চিত করার জন্য এটি করা হয়।
নন-ব্লকিং কমিট মূল থ্রেডের থেমে যাওয়ার প্রয়োজনীয়তা দূর করবে এবং প্রতিশ্রুতি পর্যায় শেষ হওয়ার জন্য অপেক্ষা করবে—কমিট কম্পোজিটর থ্রেডে একযোগে চালানোর সময় মূল থ্রেড কাজ চালিয়ে যাবে। নন-ব্লকিং কমিট-এর নেট ইফেক্ট হবে মূল থ্রেডে কাজ রেন্ডার করার জন্য নিবেদিত সময়ের একটি হ্রাস, যা মূল থ্রেডে যানজট কমিয়ে দেবে এবং কর্মক্ষমতা উন্নত করবে। এই লেখা পর্যন্ত (মার্চ 2022), আমাদের কাছে নন-ব্লকিং কমিট-এর একটি কার্যকরী প্রোটোটাইপ রয়েছে এবং আমরা কার্যক্ষমতার উপর এর প্রভাবের বিস্তারিত বিশ্লেষণ করার জন্য প্রস্তুতি নিচ্ছি।
উইংসে অপেক্ষা করা হল অফ-মেইন-থ্রেড কম্পোজিটিং , মূল থ্রেড থেকে লেয়ারাইজেশন সরানোর মাধ্যমে রেন্ডারিং ইঞ্জিনকে চিত্রের সাথে মেলে, এবং একটি ওয়ার্কার থ্রেডে নিয়ে যাওয়ার লক্ষ্য নিয়ে। নন-ব্লকিং কমিটের মতো, এটি রেন্ডারিং কাজের চাপ কমিয়ে মূল থ্রেডে যানজট কমিয়ে দেবে। কম্পোজিট আফটার পেইন্টের স্থাপত্যগত উন্নতি ছাড়া এই ধরনের একটি প্রকল্প কখনই সম্ভব হতো না।
এবং পাইপলাইনে আরও প্রকল্প রয়েছে (শ্লেষের উদ্দেশ্য)! আমরা অবশেষে একটি ভিত্তি পেয়েছি যা রেন্ডারিং কাজকে পুনরায় বিতরণ করার সাথে পরীক্ষা করা সম্ভব করে তোলে এবং আমরা কী সম্ভব তা দেখতে খুব উত্তেজিত!