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

Chris Harrelson

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

सबसे ऊंचे लेवल से शुरू करते हुए, रेंडरिंग के काम हैं:

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

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

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

• DOM स्थिति
• सीएसएस
• कैनवस
• बाहरी संसाधन, जैसे कि इमेज, वीडियो, फ़ॉन्ट, और SVG

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सभी Chromium के लिए सिर्फ़ एक Viz प्रोसेस है. आम तौर पर, ड्रॉ करने के लिए सिर्फ़ एक जीपीयू और स्क्रीन होती है.

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

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

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

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

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

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

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

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

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

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

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

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

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

ब्राउज़र प्रक्रिया

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

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

विज़ प्रोसेस

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

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

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

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

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

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

ब्लिंक रेंडरर में:

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

रेंडरिंग इवेंट लूप शेड्यूलर और रनर यह तय करता है कि इवेंट लूप पर क्या और कब चलाना है. यह रेंडरिंग को डिवाइस के डिसप्ले से मेल खाने वाली फ़्रीक्वेंसी पर शेड्यूल करता है.

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

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

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

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

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

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

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

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

टैब 1: 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>

टैब 3: baz.com html <html> … </html>

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

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

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

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

1. डेवलपर स्क्रिप्ट, foo.com के लिए रेंडर करने की प्रोसेस में DOM को बदल देती है.
2. ब्लिंक रेंडरर, कंपोज़िटर को बताता है कि उसे रेंडर होने की ज़रूरत है.
3. कंपोज़िटर विज़ को बताता है कि उसे रेंडर होने की ज़रूरत है.
4. Viz, रेंडर की शुरुआत कंपोज़िटर को वापस शुरू करने का सिग्नल देता है.
5. कंपोज़िटर, स्टार्ट सिग्नल को ब्लिंक रेंडरर पर फ़ॉरवर्ड करता है.
6. मुख्य थ्रेड इवेंट लूप रनर, दस्तावेज़ का लाइफ़साइकल चलाता है.
7. मुख्य थ्रेड, नतीजे को कंपोज़िटर थ्रेड को भेजती है.
8. कंपोज़िटर इवेंट लूप रनर, कंपोज़िटिंग लाइफ़साइकल चलाता है.
9. किसी भी रास्टर टास्क को रास्टर के लिए विज़ को भेजा जाता है (अक्सर इनमें से एक से ज़्यादा टास्क होते हैं).
10. जीपीयू पर विज़ रैस्टर कॉन्टेंट.
11. विज़, रास्टर टास्क पूरा होने के बारे में स्वीकार करते हैं. ध्यान दें: Chromium अक्सर रास्टर के पूरा होने का इंतज़ार नहीं करता. इसके बजाय, वह सिंक टोकन नाम की सुविधा का इस्तेमाल करता है. इसे रास्टर टास्क की मदद से 15वें चरण को पूरा करने से पहले पूरा करना पड़ता है.
12. एक कंपोज़िटर फ़्रेम, Viz को भेजा गया.
13. Viz, 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. Viz, foo.com रेंडर प्रोसेस, बार.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. हाइपरलिंक का डेस्टिनेशन पेज लोड होने पर, नई स्थिति रेंडर होती है. इसमें "रेंडर किया गया डीओएम" पिछले उदाहरण से मिलते-जुलते तरीके का इस्तेमाल किया जाता है. (इन बदलावों को यहां नहीं दिखाया गया है.)

खाना पैक कराकर ले जाने की सुविधा

रेंडरिंग के काम करने के तरीके को याद रखने और उसे अपने हिसाब से बनाने में बहुत समय लग सकता है.

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

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

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

---

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