रेंडरिंगNG आर्किटेक्चर

Chris Harrelson

यहां आपको पता चलेगा कि RenderingNG के कॉम्पोनेंट के हिस्से कैसे सेट अप किए जाते हैं और रेंडरिंग पाइपलाइन उनमें कैसे काम करती है.

सबसे ऊपर से शुरू करते हुए, रेंडरिंग के टास्क ये हैं:

1. स्क्रीन पर पिक्सल में कॉन्टेंट रेंडर करें.
2. कॉन्टेंट में एक से दूसरी स्थिति में विज़ुअल इफ़ेक्ट ऐनिमेट करें.
3. इनपुट के जवाब में स्क्रोल करें.
4. इनपुट को सही जगहों पर भेजें, ताकि डेवलपर स्क्रिप्ट और अन्य सबसिस्टम जवाब दे सकें.

रेंडर किए जाने वाले कॉन्टेंट में, हर ब्राउज़र टैब के लिए फ़्रेम का ट्री और ब्राउज़र इंटरफ़ेस शामिल होता है. साथ ही, टच स्क्रीन, माउस, कीबोर्ड, और अन्य हार्डवेयर डिवाइसों से मिले रॉ इनपुट इवेंट की स्ट्रीम.

हर फ़्रेम में ये चीज़ें शामिल होती हैं:

• डीओएम स्टेटस
• सीएसएस
• कैनवस
• इमेज, वीडियो, फ़ॉन्ट, और एसवीजी जैसे बाहरी रिसॉर्स

फ़्रेम एक एचटीएमएल दस्तावेज़ और उसका यूआरएल होता है. ब्राउज़र टैब में लोड किए गए वेब पेज में एक टॉप-लेवल फ़्रेम होता है. साथ ही, टॉप-लेवल दस्तावेज़ में शामिल हर iframe के लिए चाइल्ड फ़्रेम और उनके रीकर्सिव iframe वंश होते हैं.

विज़ुअल इफ़ेक्ट, बिटमैप पर लागू किया जाने वाला ग्राफ़िकल ऑपरेशन है. जैसे, स्क्रोल, ट्रांसफ़ॉर्म, क्लिप, फ़िल्टर, ओपैसिटी या ब्लेंड.

आर्किटेक्चर कॉम्पोनेंट

RenderingNG में, इन टास्क को कई चरणों और कोड घटकों में बांटा जाता है. कॉम्पोनेंट, सीपीयू की अलग-अलग प्रोसेस, थ्रेड, और उन थ्रेड में मौजूद सब-कॉम्पोनेंट में दिखते हैं. सभी वेब कॉन्टेंट के लिए, भरोसेमंद, स्केलेबल परफ़ॉर्मेंस, और बढ़ाई जा सकने वाली सुविधा देने में, इनमें से हर एक की अहम भूमिका होती है.

रेंडरिंग पाइपलाइन का स्ट्रक्चर

ऐरो, हर स्टेज के इनपुट और आउटपुट के बारे में बताते हैं. चरणों को रंग से दिखाया जाता है, ताकि यह पता चल सके कि वे कौनसी थ्रेड या प्रोसेस को लागू करते हैं. कुछ मामलों में, परिस्थितियों के हिसाब से चरण कई जगहों पर लागू हो सकते हैं. इसलिए, कुछ चरण दो रंगों में दिखते हैं. हरे रंग के चरण, रेंडर प्रोसेस के मुख्य थ्रेड को रेंडर करते हैं; पीले रंग के चरण, रेंडर प्रोसेस के कंपोजिटर को रेंडर करते हैं; और नारंगी रंग के चरण, विज़ प्रोसेस को रेंडर करते हैं.

रेंडरिंग की प्रोसेस, एक पाइपलाइन में होती है. इसमें कई चरण होते हैं और साथ ही, कई आर्टफ़ैक्ट भी बनाए जाते हैं. हर चरण में कोड को दिखाया जाता है, जो रेंडर करने के दौरान अच्छी तरह तय किया गया एक टास्क करता है. आर्टफ़ैक्ट, डेटा स्ट्रक्चर होते हैं, जो चरणों के इनपुट या आउटपुट होते हैं.

चरण इस प्रकार हैं:

1. ऐनिमेट करें: तय की गई टाइमलाइन के आधार पर, समय के साथ प्रॉपर्टी ट्री में बदलाव करें और कैलकुलेट की गई स्टाइल बदलें.
2. स्टाइल: सीएसएस को डीओएम पर लागू करें और कंप्यूट की गई स्टाइल बनाएं.
3. लेआउट: स्क्रीन पर DOM एलिमेंट का साइज़ और पोज़िशन तय करें और बदलाव न किए जा सकने वाले फ़्रैगमेंट ट्री बनाएं.
4. पेंट करने से पहले: प्रॉपर्टी ट्री का हिसाब लगाएं और ज़रूरत के हिसाब से, किसी भी मौजूदा डिसप्ले लिस्ट और जीपीयू टेक्स्चर टाइल को invalidate करें.
5. स्क्रोल: प्रॉपर्टी ट्री में बदलाव करके, दस्तावेज़ों और स्क्रोल किए जा सकने वाले डीओएम एलिमेंट के स्क्रोल ऑफ़सेट को अपडेट करें.
6. पेंट: ऐसी डिसप्ले सूची कंप्यूट करें, जो डीओएम से जीपीयू टेक्सचर टाइल को रास्टर करने का तरीका बताती हो.
7. कमिट करें: प्रॉपर्टी ट्री और डिसप्ले सूची को कंपोजिटर थ्रेड में कॉपी करें.
8. लेयर बनाएं: अलग-अलग रेस्टर और ऐनिमेशन के लिए, डिसप्ले की सूची को कंपोज़िट लेयर की सूची में बांटें.
9. रेस्टर, डिकोड, और पेंट वर्कलेट: डिसप्ले लिस्ट, कोड में बदली गई इमेज, और पेंट वर्कलेट कोड को जीपीयू टेक्सचर टाइल में बदलें.
10. चालू करें: कोई कंपोज़र फ़्रेम बनाएं. इसमें, स्क्रीन पर जीपीयू टाइल को ड्रॉ करने और उनकी पोज़िशन तय करने का तरीका दिखाया जाता है. साथ ही, इसमें विज़ुअल इफ़ेक्ट भी शामिल होते हैं.
11. एग्रीगेट करें: दिखने वाले सभी कंपोज़िटर फ़्रेम को एक ही ग्लोबल कंपोज़िटर फ़्रेम में जोड़ें.
12. ड्रॉ करें: स्क्रीन पर पिक्सल बनाने के लिए, जीपीयू पर एग्रीगेट किया गया कंपोज़िटर फ़्रेम एक्ज़ीक्यूट करें.

अगर ज़रूरत न हो, तो रेंडरिंग पाइपलाइन के चरणों को छोड़ा जा सकता है. उदाहरण के लिए, विज़ुअल इफ़ेक्ट के ऐनिमेशन और स्क्रोल करने पर, लेआउट को स्किप किया जा सकता है, प्री-पेंट किया जा सकता है, और पेंट किया जा सकता है. इसलिए, डायग्राम में ऐनिमेशन और स्क्रोल को पीले और हरे बिंदुओं से मार्क किया गया है. अगर विज़ुअल इफ़ेक्ट के लिए लेआउट, प्री-पेंट, और पेंट को छोड़ा जा सकता है, तो इन्हें पूरी तरह से कंपोजिटर थ्रेड पर चलाया जा सकता है और मुख्य थ्रेड को छोड़ा जा सकता है.

ब्राउज़र यूज़र इंटरफ़ेस (यूआई) को रेंडर करने की प्रोसेस को यहां सीधे तौर पर नहीं दिखाया गया है. हालांकि, इसे इस पाइपलाइन के आसान वर्शन के तौर पर देखा जा सकता है. असल में, इसे लागू करने के लिए ज़्यादातर कोड का इस्तेमाल किया जाता है. वीडियो (जिसे सीधे तौर पर नहीं दिखाया गया है) आम तौर पर, इंडिपेंडेंट कोड के साथ रेंडर किया जाता है, जो फ़्रेम को जीपीयू टेक्सचर टाइल में डिकोड करता है. इसके बाद, कंपोज़िटर फ़्रेम और ड्रॉ स्टेप में प्लग इन किया जाता है.

प्रोसेस और थ्रेड का स्ट्रक्चर

ध्यान दें: इस दस्तावेज़ में दिखाई गई तुलना में, Chromium के आर्किटेक्चर में ज़्यादा सीपीयू प्रोसेस और थ्रेड मौजूद हैं. ये डायग्राम सिर्फ़ उन चीज़ों पर फ़ोकस करते हैं जो रेंडर करने के लिए ज़रूरी हैं.

सीपीयू प्रोसेस

कई सीपीयू प्रोसेस का इस्तेमाल करने से, साइटों और ब्राउज़र की स्थिति के बीच परफ़ॉर्मेंस और सुरक्षा के हिसाब से अलग-अलग सेगमेंट बनते हैं. साथ ही, जीपीयू हार्डवेयर से भी परफ़ॉर्मेंस और सुरक्षा के हिसाब से अलग-अलग सेगमेंट बनते हैं.

• रेंडर करने की प्रोसेस, किसी एक साइट और टैब कॉम्बिनेशन के लिए इनपुट को रेंडर करती है, ऐनिमेट करती है, स्क्रोल करती है, और रूट करती है. रेंडर करने की कई प्रोसेस हैं.
• ब्राउज़र प्रोसेस, ब्राउज़र यूज़र इंटरफ़ेस (इसमें पता बार, टैब के टाइटल, और आइकॉन शामिल हैं) के लिए इनपुट को रेंडर करती है, ऐनिमेट करती है, और उसे रूट करती है. साथ ही, बाकी सभी इनपुट को सही रेंडर प्रोसेस पर रूट करती है. एक ब्राउज़र प्रोसेस है.
• विज़ प्रोसेस, कई रेंडर प्रोसेस और ब्राउज़र प्रोसेस से कॉम्पोज़िंग को इकट्ठा करती है. यह जीपीयू का इस्तेमाल करके रेस्टर करता है और ड्रॉ करता है. विज़ुअलाइज़ेशन की एक प्रोसेस होती है.

अलग-अलग साइटों के लिए, रेंडर करने की प्रोसेस हमेशा अलग-अलग होती है.

ध्यान दें: असल में, यह डेस्कटॉप पर हमेशा सही होता है. मोबाइल पर, सिर्फ़ तब सही होता है, जब हो सके. यह चेतावनी हर जगह लागू होती है.

आम तौर पर, एक ही साइट के कई ब्राउज़र टैब या विंडो, अलग-अलग रेंडर करने की प्रोसेस में जाती हैं. ऐसा तब तक होता है, जब तक टैब एक-दूसरे से जुड़े न हों. जैसे, एक टैब से दूसरे टैब को खोलना. डेस्कटॉप पर ज़्यादा मेमोरी का इस्तेमाल होने पर, Chromium एक ही साइट के कई टैब को एक ही रेंडर प्रोसेस में डाल सकता है. भले ही, वे टैब एक-दूसरे से जुड़े न हों.

एक ही ब्राउज़र टैब में, अलग-अलग साइटों के फ़्रेम हमेशा अलग-अलग रेंडर प्रोसेस में होते हैं. हालांकि, एक ही साइट के फ़्रेम हमेशा एक ही रेंडर प्रोसेस में होते हैं. रेंडरिंग के लिहाज़ से, कई रेंडर प्रोसेस का अहम फ़ायदा यह है कि क्रॉस-साइट iframe और टैब एक-दूसरे से परफ़ॉर्मेंस अलग-अलग होते हैं. इसके अलावा, ऑरिजिन ज़्यादा आइसोलेशन के लिए ऑप्ट इन कर सकते हैं.

Chromium के सभी वर्शन के लिए, विज़ुअलाइज़ेशन की एक ही प्रोसेस होती है. ऐसा इसलिए, क्योंकि आम तौर पर एक ही जीपीयू और स्क्रीन पर विज़ुअलाइज़ेशन किया जाता है.

विज़ुअलाइज़ेशन को अलग प्रोसेस में अलग करने से, जीपीयू ड्राइवर या हार्डवेयर में बग होने पर, विज़ुअलाइज़ेशन स्थिर रहता है. यह सुरक्षा से जुड़ी प्रोसेस को अलग रखने के लिए भी अच्छा है. यह Vulkan जैसे GPU एपीआई और सामान्य तौर पर सुरक्षा के लिए ज़रूरी है.

ब्राउज़र में कई टैब और विंडो हो सकती हैं और उन सभी में ब्राउज़र यूज़र इंटरफ़ेस (यूआई) पिक्सल होते हैं. इसलिए, आपके मन में यह सवाल आ सकता है कि ब्राउज़र की प्रोसेस सिर्फ़ एक क्यों होती है? इसकी वजह यह है कि एक समय पर उनमें से किसी एक पर ही फ़ोकस किया जाता है. असल में, न दिखने वाले ब्राउज़र टैब आम तौर पर बंद हो जाते हैं और उनकी पूरी जीपीयू मेमोरी ड्रॉप हो जाती है. हालांकि, रेंडर करने की प्रोसेस में, ब्राउज़र के यूज़र इंटरफ़ेस (यूआई) को रेंडर करने वाली जटिल सुविधाएं तेज़ी से लागू की जा रही हैं. इसे WebUI भी कहा जाता है. ऐसा परफ़ॉर्मेंस आइसोलेशन की वजह से नहीं किया जाता है, बल्कि Chromium के वेब रेंडरिंग इंजन को आसानी से इस्तेमाल करने के लिए किया जाता है.

पुराने Android डिवाइसों पर, वेबव्यू में इस्तेमाल किए जाने पर रेंडर और ब्राउज़र प्रोसेस शेयर की जाती है. आम तौर पर, यह Android पर Chromium पर लागू नहीं होता, सिर्फ़ वेबव्यू पर लागू होता है. वेबव्यू में, ब्राउज़र प्रोसेस को एम्बेड करने वाले ऐप्लिकेशन के साथ भी शेयर किया जाता है. साथ ही, वेबव्यू में सिर्फ़ एक रेंडर प्रोसेस होती है.

कभी-कभी, सुरक्षित वीडियो कॉन्टेंट को डिकोड करने के लिए भी एक यूटिलिटी प्रोसेस होती है. यह प्रोसेस पिछले डायग्राम में नहीं दिखाई गई है.

बातचीत के थ्रेड

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

• मुख्य थ्रेड, स्क्रिप्ट, रेंडरिंग इवेंट लूप, दस्तावेज़ के लाइफ़साइकल, हिट टेस्टिंग, स्क्रिप्ट इवेंट डिस्पैचिंग, और एचटीएमएल, सीएसएस, और अन्य डेटा फ़ॉर्मैट को पार्स करता है.
  • मुख्य थ्रेड के हेल्पर, इमेज बिटमैप और ब्लॉब बनाने जैसे काम करते हैं. इन कामों के लिए, कोड में बदलने या कोड से वापस बदलने की ज़रूरत होती है.
  • वेब वर्कर्स, स्क्रिप्ट चलाते हैं और OffscreenCanvas के लिए रेंडरिंग इवेंट लूप चलाते हैं.
• कंपोज़र थ्रेड, इनपुट इवेंट को प्रोसेस करता है, वेब कॉन्टेंट को स्क्रोल और ऐनिमेशन करता है, वेब कॉन्टेंट की लेयर को ऑप्टिमाइज़ करता है, और इमेज को डिकोड करने, पेंट वर्कलेट, और रेस्टर टास्क को कोऑर्डिनेट करता है.
  • कंपोज़िटर थ्रेड हेल्पर, विज़ुअल रेस्टर टास्क को मैनेज करते हैं. साथ ही, इमेज को डिकोड करने के टास्क, पेंट वर्कलेट, और फ़ॉलबैक रेस्टर को लागू करते हैं.
• मीडिया, डिम्यूक्सर या ऑडियो आउटपुट थ्रेड, वीडियो और ऑडियो स्ट्रीम को डिकोड, प्रोसेस, और सिंक करते हैं. (ध्यान रखें कि वीडियो, मुख्य रेंडरिंग पाइपलाइन के साथ-साथ चलता है.)

ऐनिमेशन के परफ़ॉर्मेंस आइसोलेशन और मुख्य थ्रेड के काम से स्क्रोल करने के लिए, मुख्य और कंपोज़िटर थ्रेड को अलग करना बेहद ज़रूरी है.

हर रेंडर प्रोसेस में सिर्फ़ एक मुख्य थ्रेड होती है. भले ही, एक ही साइट के कई टैब या फ़्रेम एक ही प्रोसेस में शामिल हो सकते हैं. हालांकि, अलग-अलग ब्राउज़र एपीआई में किए गए काम से परफ़ॉर्मेंस अलग होती है. उदाहरण के लिए, Canvas API में इमेज बिटमैप और ब्लॉब जनरेट करने की प्रोसेस, मुख्य थ्रेड की हेल्पर थ्रेड में चलती है.

इसी तरह, हर रेंडर प्रोसेस के लिए सिर्फ़ एक कंपोजिटर थ्रेड होती है. आम तौर पर, इस तरह की कोई समस्या नहीं होती कि कंपोज़िटर थ्रेड पर होने वाली सभी महंगी कार्रवाइयां, कंपोज़िटर वर्कर थ्रेड या विज़ प्रोसेस को सौंपी जाती हैं. यह काम इनपुट रूटिंग, स्क्रोलिंग या ऐनिमेशन के साथ किया जा सकता है. कंपोज़िटर वर्कर थ्रेड, Viz प्रोसेस में चलाए जाने वाले टास्क को कॉर्डिनेट करती हैं, लेकिन हर जगह GPU से तेज़ी लाने की सुविधा Chromium के कंट्रोल से बाहर की वजहों से फ़ेल हो सकती है. जैसे, ड्राइवर की गड़बड़ियां. इन स्थितियों में वर्कर थ्रेड, सीपीयू पर फ़ॉलबैक मोड में काम करता है.

कंपोजिटर वर्क थ्रेड की संख्या, डिवाइस की क्षमताओं पर निर्भर करती है. उदाहरण के लिए, डेस्कटॉप आम तौर पर ज़्यादा थ्रेड का इस्तेमाल करेंगे, क्योंकि इनमें सीपीयू कोर ज़्यादा होते हैं और मोबाइल डिवाइसों की तुलना में इनकी बैटरी कम खर्च होती है. यह स्केलिंग और स्केल डाउन का एक उदाहरण है.

रेंडर प्रोसेस थ्रेडिंग आर्किटेक्चर, ऑप्टिमाइज़ेशन के तीन अलग-अलग पैटर्न का इस्तेमाल करता है:

• हेल्पर थ्रेड: लंबे समय तक चलने वाले सबटास्क को अतिरिक्त थ्रेड पर भेजें. ऐसा करके, पैरंट थ्रेड को एक साथ अन्य अनुरोधों पर रिस्पॉन्स भेजा जा सकता है. मुख्य थ्रेड के सहायक और कंपोजिटर के सहायक थ्रेड, इस तकनीक के अच्छे उदाहरण हैं.
• मल्टीपल बफ़रिंग: रेंडर करने में लगने वाले समय को छिपाने के लिए, नया कॉन्टेंट रेंडर करते समय, पहले से रेंडर किया गया कॉन्टेंट दिखाएं. कंपोजिटर थ्रेड इस तकनीक का इस्तेमाल करती है.
• पाइपलाइन को एक साथ कई जगहों पर चलाना: एक साथ कई जगहों पर रेंडरिंग पाइपलाइन चलाएं. स्क्रोल और ऐनिमेशन, इसी तरह तेज़ी से हो सकते हैं. भले ही, मुख्य थ्रेड रेंडरिंग अपडेट हो रहा हो, लेकिन स्क्रोल और ऐनिमेशन साथ-साथ चल सकते हैं.

ब्राउज़र प्रोसेस

• रेंडर और कॉम्पोज़ करने वाली थ्रेड, ब्राउज़र यूज़र इंटरफ़ेस (यूआई) में इनपुट का जवाब देती है. साथ ही, अन्य इनपुट को सही रेंडर प्रोसेस पर भेजती है. साथ ही, ब्राउज़र यूज़र इंटरफ़ेस (यूआई) को लेआउट और पेंट करती है.
• रेंडर और कंपोज़िटिंग थ्रेड हेल्पर, इमेज डिकोड करने के टास्क और फ़ॉलबैक रास्टर या डिकोड करते हैं.

ब्राउज़र प्रोसेस रेंडर और कॉम्पोज़ करने वाली थ्रेड, रेंडर प्रोसेस के कोड और फ़ंक्शन से मिलती-जुलती होती हैं. हालांकि, मुख्य थ्रेड और कॉम्पोज़र थ्रेड को एक में जोड़ दिया जाता है. इस मामले में सिर्फ़ एक थ्रेड की ज़रूरत होती है, क्योंकि मुख्य थ्रेड के लंबे टास्क से परफ़ॉर्मेंस को अलग करने की ज़रूरत नहीं होती. ऐसा इसलिए है, क्योंकि डिज़ाइन में कोई टास्क नहीं है.

विज़ प्रोसेस

• जीपीयू की मुख्य थ्रेड, जीपीयू टेक्स्चर टाइल में सूचियां और वीडियो फ़्रेम रेस्टर करती है. साथ ही, स्क्रीन पर कंपोजिटर फ़्रेम दिखाती है.
• डिसप्ले कंपोजिटर थ्रेड, हर रेंडर प्रोसेस और ब्राउज़र प्रोसेस से कॉम्पोज़िटिंग को इकट्ठा और ऑप्टिमाइज़ करता है. साथ ही, स्क्रीन पर दिखाने के लिए, इसे एक कंपोजिटर फ़्रेम में बदल देता है.

आम तौर पर, रेस्टर और ड्रॉ एक ही थ्रेड पर होता है, क्योंकि दोनों जीपीयू संसाधनों पर निर्भर करते हैं. साथ ही, जीपीयू का मल्टी-थ्रेड वाला इस्तेमाल करना मुश्किल होता है. जीपीयू का आसानी से मल्टी-थ्रेड वाला ऐक्सेस, नए Vulkan स्टैंडर्ड को डेवलप करने की एक वजह है. Android वेबव्यू पर, ड्रॉइंग के लिए अलग ओएस-लेवल का रेंडर थ्रेड उपलब्ध होता है. इसकी वजह यह है कि किसी नेटिव ऐप्लिकेशन में वेबव्यू को कैसे एम्बेड किया जाता है. आने वाले समय में, अन्य प्लैटफ़ॉर्म पर इस तरह का थ्रेड हो सकता है.

डिसप्ले कंपोजिटर किसी दूसरी थ्रेड पर होता है, क्योंकि उसे हर समय रिस्पॉन्सिव रहना होता है. साथ ही, जीपीयू की मुख्य थ्रेड पर धीमे होने के किसी भी संभावित सोर्स को ब्लॉक नहीं करना होता. जीपीयू के मुख्य थ्रेड पर धीमे ट्रैफ़िक की एक वजह, बिना Chromium कोड के कॉल करना है, जैसे कि वेंडर के लिए खास तौर पर बनाए गए जीपीयू ड्राइवर. ये ऐसे हो सकते हैं जिनका अनुमान लगाना मुश्किल हो.

कॉम्पोनेंट का स्ट्रक्चर

हर रेंडर प्रोसेस के मुख्य या कंपोजिटर थ्रेड में, ऐसे लॉजिकल सॉफ़्टवेयर कॉम्पोनेंट होते हैं जो एक-दूसरे के साथ व्यवस्थित तरीके से इंटरैक्ट करते हैं.

मुख्य थ्रेड के कॉम्पोनेंट को रेंडर करने की प्रोसेस

Blink रेंडरर में:

• लोकल फ़्रेम ट्री फ़्रैगमेंट, लोकल फ़्रेम के ट्री और फ़्रेम में डीओएम को दिखाता है.
• DOM और कैनवस एपीआई कॉम्पोनेंट में, इन सभी एपीआई को लागू किया गया है.
• दस्तावेज़ लाइफ़साइकल रनर, रेंडरिंग पाइपलाइन के चरणों को तय किए गए चरण तक लागू करता है.
• इनपुट इवेंट हिट टेस्टिंग और डिस्पैचिंग कॉम्पोनेंट, हिट टेस्ट को लागू करता है, ताकि यह पता लगाया जा सके कि किसी इवेंट से कौनसा DOM एलिमेंट टारगेट किया गया है. साथ ही, यह इनपुट इवेंट डिस्पैचिंग एल्गोरिदम और डिफ़ॉल्ट व्यवहार को चलाता है.

रेंडरिंग इवेंट लूप शेड्यूलर और रनर यह तय करता है कि इवेंट लूप पर क्या और कब चलाया जाए. यह डिवाइस के डिसप्ले के हिसाब से, रेंडरिंग को शेड्यूल करता है.

लोकल फ़्रेम ट्री फ़्रैगमेंट थोड़े मुश्किल होते हैं. याद रखें कि फ़्रेम ट्री, मुख्य पेज और उसके चाइल्ड iframes होते हैं. अगर कोई फ़्रेम किसी रेंडर प्रोसेस में रेंडर किया जाता है, तो वह उस प्रोसेस के लिए लोकल होता है. अगर ऐसा नहीं होता है, तो वह रिमोट होता है.

फ़्रेम को रेंडर करने की प्रोसेस के हिसाब से, उन्हें रंगा जा सकता है. पिछली इमेज में, हरे रंग के सभी फ़्रेम को रेंडर करने की एक प्रोसेस में दिखाया गया है. नारंगी रंग वाले सर्कल, दूसरे फ़्रेम में और नीले रंग के सर्कल तीसरी इमेज में हैं.

लोकल फ़्रेम ट्री फ़्रैगमेंट, फ़्रेम ट्री में एक ही रंग का जुड़ा हुआ कॉम्पोनेंट होता है. इमेज में चार लोकल फ़्रेम ट्री हैं: साइट A के लिए दो, साइट B के लिए एक, और साइट C के लिए एक. हर लोकल फ़्रेम ट्री को अपना Blink रेंडरर कॉम्पोनेंट मिलता है. किसी लोकल फ़्रेम ट्री का Blink रेंडरर, अन्य लोकल फ़्रेम ट्री के रेंडर करने की प्रोसेस में हो सकता है या नहीं. यह इस बात से तय होता है कि रेंडर प्रोसेस कैसे चुनी जाती हैं, जैसा कि पहले बताया गया है.

रेंडर प्रोसेस कंपोजिटर थ्रेड का स्ट्रक्चर

रेंडर प्रोसेस कंपोजिटर के कॉम्पोनेंट में ये शामिल हैं:

• यह एक डेटा हैंडलर होता है, जो कंपोज़िट की गई लेयर की सूची, डिसप्ले लिस्ट, और प्रॉपर्टी ट्री को बनाए रखता है.
• लाइफ़साइकल रनर, जो ऐनिमेट करता है, स्क्रोल करता है, कंपोज़िट, रास्टर चलाता है, और रेंडरिंग पाइपलाइन के चरणों को डिकोड और चालू करता है. (ध्यान रखें कि ऐनिमेशन और स्क्रोल, मुख्य थ्रेड और कंपोज़िटर, दोनों में हो सकता है.)
• इनपुट और हिट टेस्ट हैंडलर, कॉम्पोज़ की गई लेयर के रिज़ॉल्यूशन पर इनपुट प्रोसेसिंग और हिट टेस्ट करता है. इससे यह तय किया जाता है कि कॉम्पोज़र थ्रेड पर स्क्रोलिंग जेस्चर चलाए जा सकते हैं या नहीं. साथ ही, यह भी तय किया जाता है कि हिट टेस्ट के लिए किस रेंडर प्रोसेस को टारगेट किया जाना चाहिए.

आर्किटेक्चर के इस्तेमाल का उदाहरण

इस उदाहरण में तीन टैब हैं:

पहला टैब: foo.com

<html>
  <iframe id=one src="foo.com/other-url"></iframe>
  <iframe  id=two src="bar.com"></iframe>
</html>

टैब 2: bar.com

<html>
 …
</html>

तीसरा टैब: baz.com html <html> … </html>

इन टैब की प्रोसेस, थ्रेड, और कॉम्पोनेंट का स्ट्रक्चर इस तरह से दिखता है:

आइए, रेंडरिंग के चार मुख्य टास्क में से हर एक के लिए एक उदाहरण देखें. रिमाइंडर:

1. स्क्रीन पर कॉन्टेंट को पिक्सल में रेंडर करें.
2. कॉन्टेंट में एक से दूसरी स्थिति में विज़ुअल इफ़ेक्ट Animate करें.
3. इनपुट के जवाब में स्क्रोल करें.
4. इनपुट को सही जगहों पर रूट करें, ताकि डेवलपर स्क्रिप्ट और अन्य सबसिस्टम जवाब दे सकें.

पहले टैब के लिए बदले गए DOM को रेंडर करने के लिए:

1. डेवलपर स्क्रिप्ट, foo.com के लिए रेंडर करने की प्रोसेस में DOM को बदलती है.
2. Blink रेंडरर, कंपोज़िटर को बताता है कि उसे रेंडर करने की ज़रूरत है.
3. कंपोजिटर, विज़ को बताता है कि उसे रेंडर करने की ज़रूरत है.
4. विज़ुअलाइज़ेशन, रेंडर शुरू होने का सिग्नल कंपोजिटर को भेजता है.
5. कंपोजिटर, शुरू करने का सिग्नल Blink रेंडरर को भेजता है.
6. मुख्य थ्रेड इवेंट लूप रनर, दस्तावेज़ का लाइफ़साइकल चलाता है.
7. मुख्य थ्रेड, नतीजे को कंपोजिटर थ्रेड पर भेजती है.
8. कंपोजिटर इवेंट लूप रनर, कंपोजिटिंग लाइफ़साइकल चलाता है.
9. किसी भी रास्टर टास्क को रास्टर के लिए विज़ को भेजा जाता है (अक्सर इनमें से एक से ज़्यादा टास्क होते हैं).
10. विज़ुअलाइज़ेशन, जीपीयू पर कॉन्टेंट को रेस्टर करता है.
11. Viz, रेस्टर टास्क के पूरा होने की पुष्टि करता है. ध्यान दें: आम तौर पर, Chromium रेस्टर के पूरा होने का इंतज़ार नहीं करता. इसके बजाय, वह सिंक टोकन का इस्तेमाल करता है. इसे 15वें चरण के शुरू होने से पहले, रेस्टर टास्क से हल करना होता है.
12. Viz को एक कंपोजिटर फ़्रेम भेजा जाता है.
13. विज़, foo.com की रेंडर प्रोसेस, bar.com के iframe की रेंडर प्रोसेस, और ब्राउज़र यूज़र इंटरफ़ेस (यूआई) के लिए, कंपोज़िटर फ़्रेम को इकट्ठा करता है.
14. विज़ुअलाइज़ेशन, ड्रॉ को शेड्यूल करता है.
15. विज़ुअलाइज़ेशन, एग्रीगेट किए गए कंपोजिटर फ़्रेम को स्क्रीन पर दिखाता है.

दूसरे टैब पर, सीएसएस ट्रांसफ़ॉर्म ट्रांज़िशन को ऐनिमेट करने के लिए:

1. bar.com की रेंडर प्रोसेस के लिए कॉम्पोज़र थ्रेड, मौजूदा प्रॉपर्टी ट्री में बदलाव करके, अपने कॉम्पोज़र इवेंट लूप में ऐनिमेशन को टिक करता है. इसके बाद, कंपोजिटर लाइफ़साइकल फिर से चलता है. (रैस्टर और डिकोड करने वाले टास्क हो सकते हैं, लेकिन इन्हें यहां नहीं दिखाया गया है.)
2. Viz को एक कंपोजिटर फ़्रेम भेजा जाता है.
3. Viz, foo.com रेंडर प्रोसेस, बार.com रेंडर प्रोसेस, और ब्राउज़र यूज़र इंटरफ़ेस (यूआई) के लिए कंपोज़िटर फ़्रेम को एग्रीगेट करता है.
4. विज़ुअलाइज़ेशन, ड्रॉ को शेड्यूल करता है.
5. विज़ुअलाइज़ेशन, एग्रीगेट किए गए कंपोजिटर फ़्रेम को स्क्रीन पर दिखाता है.

तीसरे टैब पर वेब पेज को स्क्रोल करने के लिए:

1. ब्राउज़र प्रोसेस में input इवेंट (माउस, टच या कीबोर्ड) का क्रम आता है.
2. हर इवेंट को baz.com की रेंडर प्रोसेस कंपोजिटर थ्रेड पर भेजा जाता है.
3. कंपोज़िटर यह तय करता है कि मुख्य थ्रेड को इवेंट के बारे में जानने की ज़रूरत है या नहीं.
4. ज़रूरी होने पर, इवेंट को मुख्य थ्रेड पर भेजा जाता है.
5. मुख्य थ्रेड, input इवेंट लिसनर (pointerdown, touchstar, pointermove, touchmove या wheel) को ट्रिगर करता है, ताकि यह पता लगाया जा सके कि लिसनर, इवेंट पर preventDefault को कॉल करेंगे या नहीं.
6. मुख्य थ्रेड यह बताती है कि preventDefault को कंपोजिटर में कॉल किया गया था या नहीं.
7. ऐसा न होने पर, इनपुट इवेंट को ब्राउज़र प्रोसेस में वापस भेज दिया जाता है.
8. ब्राउज़र प्रोसेस, इसे हाल ही के अन्य इवेंट के साथ जोड़कर स्क्रोल जेस्चर में बदल देती है.
9. स्क्रोल जेस्चर को फिर से baz.com की रेंडर प्रोसेस कंपोजिटर थ्रेड पर भेजा जाता है,
10. स्क्रॉल वहां लागू होता है और bar.com के रेंडर प्रोसेस के लिए कॉम्पोज़र थ्रेड, अपने कॉम्पोज़र इवेंट लूप में ऐनिमेशन को टिक करता है. इसके बाद, प्रॉपर्टी ट्री में स्क्रोल ऑफ़सेट में बदलाव होता है और कंपोजिटर लाइफ़साइकल फिर से चलता है. यह मुख्य थ्रेड को scroll इवेंट (यहां नहीं दिखाया गया है) ट्रिगर करने के लिए भी कहता है.
11. Viz को एक कंपोजिटर फ़्रेम भेजा जाता है.
12. विज़ुअलाइज़ेशन, foo.com की रेंडर प्रोसेस, bar.com की रेंडर प्रोसेस, और ब्राउज़र यूज़र इंटरफ़ेस (यूआई) के लिए, कंपोज़िटर फ़्रेम को इकट्ठा करता है.
13. विज़ुअलाइज़ेशन, ड्रॉ को शेड्यूल करता है.
14. विज़ुअलाइज़ेशन, एग्रीगेट किए गए कंपोजिटर फ़्रेम को स्क्रीन पर दिखाता है.

ध्यान दें: पहले इनपुट इवेंट के बाद, हर इनपुट इवेंट में तीसरे और चौथे चरण को छोड़ा जा सकता है, क्योंकि स्क्रॉल पहले ही शुरू हो चुका है. स्क्रिप्ट, scroll इवेंट के ज़रिए इसे देख सकती हैं और इसमें रुकावट नहीं डाल सकतीं.

टैब पहले पर iframe #two में हाइपरलिंक पर किसी click इवेंट को रूट करने के लिए:

1. ब्राउज़र प्रोसेस में कोई input इवेंट (माउस, टच या कीबोर्ड) आता है. यह यह तय करने के लिए, एक अनुमानित हिट टेस्ट करता है कि bar.com iframe रेंडर प्रोसेस को क्लिक मिलना चाहिए या नहीं. साथ ही, उसे वहां भेजता है.
2. bar.com के लिए कॉम्पोज़र थ्रेड, click इवेंट को bar.com के लिए मुख्य थ्रेड पर भेजता है और उसे प्रोसेस करने के लिए, रेंडरिंग इवेंट लूप टास्क को शेड्यूल करता है.
3. bar.com की मुख्य थ्रेड के लिए इनपुट इवेंट प्रोसेसर, हिट टेस्ट करता है, ताकि यह पता लगाया जा सके कि iframe में किस DOM एलिमेंट पर क्लिक किया गया था. साथ ही, स्क्रिप्ट को देखने के लिए click इवेंट ट्रिगर करता है. preventDefault न सुनने पर, यह हाइपरलिंक पर ले जाता है.
4. हाइपरलिंक के डेस्टिनेशन पेज के लोड होने पर, नई स्थिति रेंडर की जाती है. इसके लिए, "बदले गए डीओएम को रेंडर करें" के पिछले उदाहरण में बताए गए तरीके का इस्तेमाल किया जाता है. (इन बदलावों को यहां नहीं दिखाया गया है.)

सीखने लायक अहम बातें

रेंडरिंग के काम करने के तरीके को याद रखने और उसे समझने में काफ़ी समय लग सकता है.

सबसे अहम बात यह है कि रेंडरिंग पाइपलाइन को, बड़े पैमाने पर मॉड्यूलराइज़ेशन और बारीकियों पर ध्यान देकर, कई हिस्सों में बांटा गया है. इसके बाद, इन कॉम्पोनेंट को पैरलल प्रोसेस और थ्रेड में बांटा गया है, ताकि स्केलेबल परफ़ॉर्मेंस और बढ़ाने के अवसरों को बढ़ाया जा सके.

हर कॉम्पोनेंट, आधुनिक वेब ऐप्लिकेशन की परफ़ॉर्मेंस और सुविधाओं को चालू करने में अहम भूमिका निभाता है.

मुख्य डेटा स्ट्रक्चर के बारे में पढ़ते रहें, जो कि कोड कॉम्पोनेंट के रूप में रेस्पॉनिंग करने के लिए भी उतने ही ज़रूरी हैं.

---

इलस्ट्रेशन: यूना क्रेवेट.