पिछली पोस्ट में, मैंने अच्छा परफ़ॉर्म करने के लिए रेंडर किए जा रहे आर्किटेक्चर से जुड़े लक्ष्यों और मुख्य प्रॉपर्टी के बारे में खास जानकारी दी थी. इस पोस्ट में कॉम्पोनेंट के हिस्सों को सेट अप करने और उनमें रेंडर करने के तरीके के बारे में बताया गया है.
सबसे ऊपर वाले लेवल से शुरू करके और फिर वहां से ड्रिल-डाउन करते समय, रेंडरिंग के ये काम हैं:
- स्क्रीन पर पिक्सल में कॉन्टेंट को रेंडर करें.
- एक स्थिति से दूसरी स्थिति में कॉन्टेंट पर विज़ुअल इफ़ेक्ट को ऐनिमेट करें.
- इनपुट के जवाब में स्क्रोल करें.
- सही जगहों पर असरदार तरीके से इनपुट दें, ताकि डेवलपर स्क्रिप्ट और अन्य सबसिस्टम जवाब दे सकें.
रेंडर किए जाने वाले कॉन्टेंट, हर ब्राउज़र टैब के लिए फ़्रेम के एक ट्री के साथ-साथ ब्राउज़र के यूज़र इंटरफ़ेस (यूआई) के तौर पर दिखते हैं. साथ ही, टचस्क्रीन, माउस, कीबोर्ड, और अन्य हार्डवेयर डिवाइसों से रॉ इनपुट इवेंट की स्ट्रीम.
हर फ़्रेम में ये चीज़ें शामिल होती हैं:
- DOM स्थिति
- सीएसएस
- कैनवस
- बाहरी संसाधन, जैसे कि इमेज, वीडियो, फ़ॉन्ट, और SVG
फ़्रेम एक एचटीएमएल दस्तावेज़ होता है. साथ ही, इसका यूआरएल भी होता है. ब्राउज़र टैब में लोड किए गए किसी वेब पेज में टॉप लेवल का फ़्रेम, टॉप लेवल के दस्तावेज़ में शामिल हर iframe के लिए चाइल्ड फ़्रेम, और बार-बार आने वाले iframe डिसेंडेंट होते हैं.
विज़ुअल इफ़ेक्ट, बिट मैप पर लागू किया जाने वाला ग्राफ़िक इफ़ेक्ट है. जैसे, स्क्रोल करना, ट्रांसफ़ॉर्म करना, क्लिप, फ़िल्टर, ओपैसिटी या ब्लेंड करना.
आर्किटेक्चर कॉम्पोनेंट
रेंडरिंगNG में, इन टास्क को सही तरीके से कई स्टेज और कोड कॉम्पोनेंट में बांटा जाता है. कॉम्पोनेंट, उन थ्रेड में अलग-अलग सीपीयू प्रोसेस, थ्रेड, और सब-कॉम्पोनेंट में खत्म होते हैं. ये सभी चीज़ें, सभी वेब कॉन्टेंट के लिए भरोसेमंद, बढ़ाने लायक परफ़ॉर्मेंस, और एक्सटेंसिटी हासिल करने में अहम भूमिका निभाती हैं.
पाइपलाइन स्ट्रक्चर रेंडर किया जा रहा है
रेंडर करने की प्रोसेस, पाइपलाइन में होती है. इसमें कई स्टेज और आर्टफ़ैक्ट बनाए जाते हैं. हर स्टेज उस कोड को दिखाते हैं जो रेंडरिंग में एक तय काम करता है. आर्टफ़ैक्ट ऐसे डेटा स्ट्रक्चर हैं जो स्टेज के इनपुट या आउटपुट हैं. डायग्राम में इनपुट या आउटपुट ऐरो से दिखाए गए हैं.
इस ब्लॉग पोस्ट में आर्टफ़ैक्ट के बारे में ज़्यादा जानकारी नहीं दी गई है. इसके बारे में अगली पोस्ट में चर्चा की जाएगी: मुख्य डेटा स्ट्रक्चर और रेंडरिंगNG में उनकी भूमिकाएं.
पाइपलाइन के चरण
पहले वाले डायग्राम में, स्टेज को रंगों से नोट किया गया है, जिससे यह पता चलता है कि वे किस थ्रेड या प्रोसेस में काम करते हैं:
- हरा: प्रोसेस की मुख्य थ्रेड रेंडर करने की प्रक्रिया
- पीला: रेंडर प्रोसेस कंपोज़िटर
- नारंगी: विज़ुअलाइज़ेशन प्रोसेस
कुछ मामलों में, स्थिति के हिसाब से वे कई जगहों पर काम कर सकते हैं. इसलिए, कुछ के दो रंग होते हैं.
ये चरण हैं:
- ऐनिमेट करें: कंप्यूट किए गए स्टाइल को बदलें और डिक्लेरेटिव टाइमलाइन के आधार पर समय के साथ प्रॉपर्टी ट्री में बदलाव करें.
- स्टाइल: डीओएम पर सीएसएस लागू करें और कंप्यूटेड स्टाइल बनाएं.
- लेआउट: स्क्रीन पर डीओएम एलिमेंट का साइज़ और पोज़िशन तय करने के साथ-साथ, नहीं बदला जा सकने वाला फ़्रैगमेंट ट्री बनाएं.
- प्री-पेंट: प्रॉपर्टी ट्री को कंप्यूट करें और किसी भी मौजूदा डिसप्ले लिस्ट और जीपीयू टेक्स्चर टाइल को ज़रूरत के मुताबिक invalidate करें.
- स्क्रोल करने के लिए: प्रॉपर्टी ट्री में बदलाव करके, दस्तावेज़ों और स्क्रोल किए जा सकने वाले डीओएम एलिमेंट के स्क्रोल ऑफ़सेट को अपडेट करें.
- पेंट: एक ऐसी डिसप्ले सूची का इस्तेमाल करें जिसमें डीओएम से जीपीयू टेक्सचर टाइल को रास्टर करने का तरीका बताया गया है.
- कम करें: प्रॉपर्टी ट्री और डिसप्ले सूची को कंपोज़िटर थ्रेड में कॉपी करें.
- लेयराइज़: इंडिपेंडेंट रास्टराइज़ेशन और ऐनिमेशन के लिए, डिसप्ले सूची को कंपोज़िट की गई लेयर की सूची में बांट दें.
- रास्टर, डिकोड, और पेंट करें: डिसप्ले लिस्ट और कोड में बदली गई इमेज को पेंट करें और वर्कलेट कोड को जीपीयू टेक्सचर टाइल में बदलें.
- चालू करें: एक कंपोज़िटर फ़्रेम बनाएं. इससे, विज़ुअल इफ़ेक्ट के साथ स्क्रीन पर जीपीयू टाइल बनाने और उन्हें सही जगह पर लाने का तरीका पता चलता है.
- एग्रीगेट: दिखने वाले सभी कंपोज़िटर फ़्रेम से कंपोज़िटर फ़्रेम को एक ही ग्लोबल कंपोज़िटर फ़्रेम में मिलाएं.
- ड्रॉ करें: स्क्रीन पर पिक्सल बनाने के लिए, जीपीयू पर एग्रीगेट किए गए कंपोज़िटर फ़्रेम को एक्ज़ीक्यूट करें.
ज़रूरत न होने पर, रेंडरिंग पाइपलाइन के चरणों को स्किप किया जा सकता है. उदाहरण के लिए, विज़ुअल इफ़ेक्ट के ऐनिमेशन और स्क्रोल करने पर, लेआउट, प्री-पेंट, और पेंट की सुविधा को स्किप किया जा सकता है. इसी वजह से डायग्राम और स्क्रोल पर, पीले और हरे रंग के बिंदु दिखते हैं. अगर विज़ुअल इफ़ेक्ट के लिए लेआउट, प्री-पेंट, और पेंट को स्किप किया जा सकता है, तो उन्हें कंपोज़िटर थ्रेड पर पूरी तरह चलाया जा सकता है और मुख्य थ्रेड को छोड़ा जा सकता है.
ब्राउज़र यूज़र इंटरफ़ेस (यूआई) रेंडरिंग को सीधे यहां नहीं दिखाया गया है. हालांकि, ऐसा माना जा सकता है कि इसे समान पाइपलाइन का आसान वर्शन माना जा सकता है (असल में, इसके लागू होने पर ज़्यादातर कोड शेयर किए जाते हैं). वीडियो (इसे सीधे तौर पर नहीं दिखाया गया है) आम तौर पर इंडिपेंडेंट कोड के ज़रिए रेंडर होता है जो फ़्रेम को जीपीयू टेक्सचर टाइल में डिकोड करता है. इसके बाद, इन्हें कंपोज़िटर फ़्रेम और ड्रॉ स्टेप में प्लग किया जाता है.
प्रोसेस और थ्रेड का स्ट्रक्चर
सीपीयू से जुड़ी प्रोसेस
कई सीपीयू प्रोसेस इस्तेमाल करने से, साइटों और ब्राउज़र की स्थिति के बीच परफ़ॉर्मेंस और सुरक्षा अलग-अलग होती है. साथ ही, जीपीयू हार्डवेयर की मदद से स्थिरता और सुरक्षा अलग-अलग बनी रहती है.
- रेंडर करने की प्रोसेस, किसी एक साइट और टैब के कॉम्बिनेशन के लिए इनपुट को रेंडर करती है, ऐनिमेशन के तौर पर दिखाती है, स्क्रोल करती है, और रूट करती है. इमेज बनाने की कई प्रोसेस हैं.
- ब्राउज़र प्रोसेस, ब्राउज़र के यूआई (इसमें यूआरएल बार, टैब के टाइटल, और आइकॉन शामिल हैं) के लिए इनपुट को रेंडर करता है, ऐनिमेट करता है, और रूट करता है. साथ ही, बचे हुए सारे इनपुट को सही रेंडर प्रोसेस पर रूट करता है. इसमें ब्राउज़र की सिर्फ़ एक प्रोसेस होती है.
- Viz प्रोसेस में, रेंडर करने की कई प्रोसेस और ब्राउज़र प्रोसेस को इकट्ठा किया जाता है. यह जीपीयू का इस्तेमाल करके रास्टर और ड्रॉ करता है. इसमें सिर्फ़ एक Viz प्रोसेस मौजूद है.
अलग-अलग साइटों पर रेंडर करने की प्रोसेस हमेशा अलग-अलग होती है. (असल में, हमेशा डेस्कटॉप पर; जब भी मुमकिन हो मोबाइल पर. मैं नीचे "हमेशा" लिखूंगा, लेकिन यह चेतावनी पूरी तरह लागू होती है.)
एक ही साइट के कई ब्राउज़र टैब या विंडो आम तौर पर, रेंडर करने की अलग-अलग प्रोसेस में जाते हैं. हालांकि, अगर दोनों टैब एक-दूसरे से जुड़े हों (जब एक टैब या विंडो एक-दूसरे से खोलना). डेस्कटॉप पर ज़्यादा मेमोरी के दबाव में, Chromium एक ही साइट के कई टैब को रेंडर करने की एक ही प्रोसेस में डाल सकता है, भले ही वे एक-दूसरे से जुड़े न हों.
एक ही ब्राउज़र टैब में, अलग-अलग साइटों के फ़्रेम हमेशा एक-दूसरे से अलग-अलग रेंडर प्रोसेस में होते हैं लेकिन एक ही साइट के फ़्रेम हमेशा एक ही रेंडर प्रोसेस में होते हैं. रेंडरिंग के नज़रिए से, कई रेंडर प्रोसेस का एक अहम फ़ायदा यह है कि क्रॉस-साइट iframe और टैब एक-दूसरे से परफ़ॉर्मेंस आइसोलेशन पाते हैं. इसके अलावा, ऑरिजिन को और भी ज़्यादा आइसोलेशन के लिए ऑप्ट किया जा सकता है.
पूरे Chromium के लिए, सिर्फ़ एक Viz प्रोसेस मौजूद है. आम तौर पर, एक ही जीपीयू और स्क्रीन होती है, जिस पर ड्रॉ किया जा सकता है. Viz को उसकी अपनी प्रोसेस में अलग करना, जीपीयू ड्राइवर या हार्डवेयर में आने वाली गड़बड़ियों का सामना करने के लिए अच्छा है. यह सिक्योरिटी आइसोलेशन के लिए भी अच्छा है, जो Vulkan जैसे जीपीयू एपीआई के लिए ज़रूरी है. यह सामान्य सुरक्षा के लिए भी ज़रूरी है.
ब्राउज़र में कई टैब और विंडो हो सकती हैं और सभी में ब्राउज़र के यूज़र इंटरफ़ेस (यूआई) पिक्सल बनाए जा सकते हैं. इसलिए, आपको हैरानी होगी कि एक ही ब्राउज़र प्रोसेस क्यों है? इसकी वजह यह होती है कि एक समय पर, उनमें से सिर्फ़ एक पर ही फ़ोकस होता है. असल में, दिखाई न देने वाले ब्राउज़र टैब ज़्यादातर बंद हो जाते हैं और उनकी जीपीयू मेमोरी कम हो जाती है. हालांकि, ब्राउज़र के यूज़र इंटरफ़ेस (यूआई) रेंडरिंग की जटिल सुविधाएं, रेंडर करने की प्रोसेस में तेज़ी से लागू की जा रही हैं. इन्हें WebUI कहा जाता है. ऐसा सिर्फ़ परफ़ॉर्मेंस को अलग करने की वजह से नहीं किया गया है, बल्कि Chromium के वेब रेंडरिंग इंजन के आसानी से इस्तेमाल का फ़ायदा लेने के लिए है.
पुराने Android डिवाइस पर, वेबव्यू में इस्तेमाल किए जाने पर रेंडर और ब्राउज़र प्रोसेस को शेयर किया जाता है (यह आम तौर पर Android पर Chromium पर लागू नहीं होता, सिर्फ़ वेबव्यू पर लागू होता है). वेबव्यू पर, ब्राउज़र प्रोसेस को एम्बेड करने वाले ऐप्लिकेशन के साथ भी शेयर किया जाता है. और वेबव्यू में रेंडर करने की सिर्फ़ एक प्रोसेस होती है.
कभी-कभी सुरक्षित वीडियो कॉन्टेंट को डिकोड करने के लिए, एक यूटिलिटी प्रोसेस भी होती है. इस प्रक्रिया को ऊपर नहीं दिखाया गया है.
बातचीत के थ्रेड
धीमी रफ़्तार से काम करने, पाइपलाइन साथ-साथ चलने, और कई बार बफ़र होने की स्थिति में भी थ्रेड, परफ़ॉर्मेंस को अलग-अलग रखने और जवाब देने में मदद करते हैं.
- मुख्य थ्रेड, स्क्रिप्ट, रेंडरिंग इवेंट लूप, दस्तावेज़ की लाइफ़साइकल, हिट टेस्टिंग, स्क्रिप्ट इवेंट डिस्पैच करने, और एचटीएमएल, सीएसएस, और अन्य डेटा फ़ॉर्मैट को पार्स करने जैसे काम करता है.
- मुख्य थ्रेड हेल्पर, इमेज के बिटमैप और ब्लॉब बनाने जैसे काम करते हैं. इनको कोड में बदलने या डिकोड करने की ज़रूरत होती है.
- वेब वर्कर स्क्रिप्ट चलाएं और OffscreenCanvas के लिए एक रेंडरिंग इवेंट लूप.
- कंपोज़िटर थ्रेड इनपुट इवेंट को प्रोसेस करता है,
वेब कॉन्टेंट की स्क्रोलिंग और ऐनिमेशन को प्रोसेस करता है, वेब कॉन्टेंट के बेहतर लेयराइज़ेशन की गणना करता है,
इमेज डिकोड, पेंट वर्कलेट, और रास्टर टास्क को कोऑर्डिनेट करता है.
- कंपोज़िट थ्रेड हेल्पर Viz रास्टर टास्क को कोऑर्डिनेट करते हैं और इमेज डिकोड करने के टास्क एक्ज़ीक्यूट करते हैं, वर्कलेट को पेंट करते हैं, और फ़ॉलबैक रास्टर हैं.
- मीडिया, डीमक्सर या ऑडियो आउटपुट थ्रेड वीडियो और ऑडियो स्ट्रीम को डिकोड, प्रोसेस और सिंक करते हैं. (याद रखें कि वीडियो मुख्य रेंडरिंग पाइपलाइन के साथ-साथ काम करता है.)
मुख्य थ्रेड के काम से ऐनिमेशन और स्क्रोलिंग के परफ़ॉर्मेंस आइसोलेशन के लिए, मुख्य और कंपोज़िटर थ्रेड को अलग करना बहुत ज़रूरी है.
हर रेंडर प्रोसेस के लिए सिर्फ़ एक मुख्य थ्रेड होता है, भले ही एक ही साइट के कई टैब या फ़्रेम एक ही प्रोसेस में आ सकते हैं. हालांकि, अलग-अलग ब्राउज़र एपीआई में किए गए काम की वजह से परफ़ॉर्मेंस अलग होती है. उदाहरण के लिए, कैनवस एपीआई में इमेज के बिटमैप और ब्लॉब जनरेट करना, मुख्य थ्रेड हेल्पर थ्रेड में चलता है.
इसी तरह, हर रेंडर प्रोसेस में सिर्फ़ एक कंपोज़िटर थ्रेड होता है. आम तौर पर, इसमें सिर्फ़ एक समस्या होती है, क्योंकि कंपोज़िटर थ्रेड पर होने वाले सभी महंगे ऑपरेशन या तो कंपोज़िटर वर्कर थ्रेड या Viz प्रोसेस को सौंपे जाते हैं. यह काम इनपुट रूटिंग, स्क्रोलिंग या ऐनिमेशन के साथ साथ-साथ किया जा सकता है. कंपोज़िटर वर्कर थ्रेड, Viz प्रोसेस में चलने वाले टास्क के साथ मिलकर काम करते हैं, लेकिन हर जगह जीपीयू की रफ़्तार Chromium के कंट्रोल से बाहर की वजहों, जैसे कि ड्राइवर की गड़बड़ी की वजह से काम नहीं कर सकती. इन स्थितियों में, वर्कर थ्रेड, सीपीयू पर फ़ॉलबैक मोड में काम करेगा.
कंपोज़िटर वर्कर थ्रेड की संख्या, डिवाइस की क्षमताओं पर निर्भर करती है. उदाहरण के लिए, डेस्कटॉप पर आम तौर पर ज़्यादा थ्रेड इस्तेमाल होते हैं, क्योंकि उनमें ज़्यादा सीपीयू होते हैं और मोबाइल डिवाइस की तुलना में इनकी बैटरी कम होती है. यह स्केल अप और स्केलिंग का एक उदाहरण है.
यह जानना भी दिलचस्प है कि रेंडर प्रोसेस थ्रेडिंग आर्किटेक्चर, तीन अलग-अलग ऑप्टिमाइज़ेशन पैटर्न का इस्तेमाल करता है:
- हेल्पर थ्रेड: लंबे समय तक चलने वाले सबटास्क को अतिरिक्त थ्रेड के लिए बंद करें, ताकि पैरंट थ्रेड एक साथ चल रहे अन्य अनुरोधों के लिए रिस्पॉन्सिव हो. मुख्य थ्रेड हेल्पर और कंपोज़िटर हेल्पर थ्रेड इस तकनीक के अच्छे उदाहरण हैं.
- एक से ज़्यादा बफ़रिंग: नए कॉन्टेंट को रेंडर करते समय, पहले से रेंडर किया गया कॉन्टेंट दिखाना. इससे, रेंडर होने में लगने वाले समय को कम किया जा सकता है. कंपोज़िटर थ्रेड इस तकनीक का इस्तेमाल करता है.
- पाइपलाइन को साथ में चलाना: रेंडरिंग पाइपलाइन को एक साथ कई जगहों पर चलाना. मुख्य थ्रेड रेंडरिंग अपडेट होने पर भी स्क्रोल और ऐनिमेशन तेज़ी से काम कर सकते हैं, क्योंकि स्क्रोल और ऐनिमेशन साथ-साथ चल सकते हैं.
ब्राउज़र प्रोसेस
- रेंडर और कंपोज़िटिंग थ्रेड ब्राउज़र के यूआई में मौजूद इनपुट का जवाब देता है, दूसरे इनपुट को सही रेंडर प्रोसेस पर रूट करता है, ब्राउज़र के यूज़र इंटरफ़ेस को लेआउट करता और पेंट करता है.
- रेंडर और कंपोज़िटिंग थ्रेड हेल्पर इमेज को डिकोड करने और फ़ॉलबैक रास्टर या डिकोड करने के टास्क करते हैं.
ब्राउज़र प्रोसेस रेंडर और कंपोज़िटिंग थ्रेड, रेंडर करने की प्रोसेस के कोड और उसके फ़ंक्शन की तरह ही होते हैं. अंतर सिर्फ़ इतना है कि मुख्य थ्रेड और कंपोज़िटर थ्रेड को एक साथ मिला दिया गया है. इस मामले में सिर्फ़ एक थ्रेड की ज़रूरत है, क्योंकि मुख्य थ्रेड के लंबे टास्क से परफ़ॉर्मेंस आइसोलेशन की कोई ज़रूरत नहीं है. ऐसा इसलिए है, क्योंकि डिज़ाइन के हिसाब से ऐसा कोई भी थ्रेड नहीं है.
विज़ुअल प्रोसेस
- GPU मुख्य थ्रेड रास्टर, सूची और वीडियो फ़्रेम को जीपीयू टेक्सचर टाइल में दिखाता है और कंपोज़िटर फ़्रेम को स्क्रीन पर ड्रॉ करता है.
- डिसप्ले कंपोज़िटर थ्रेड, रेंडर करने की हर प्रोसेस और ब्राउज़र प्रोसेस के कंपोज़िटर को एक साथ मिलाकर, उन्हें ऑप्टिमाइज़ करता है. इससे, स्क्रीन पर प्रज़ेंटेशन देने के लिए, एक ही कंपोज़िटर फ़्रेम का इस्तेमाल किया जा सकता है.
रास्टर और ड्रॉ आम तौर पर एक ही थ्रेड में होते हैं, क्योंकि दोनों ही जीपीयू के संसाधनों पर निर्भर होते हैं. साथ ही, जीपीयू का मल्टी-थ्रेड इस्तेमाल करना मुश्किल होता है (जीपीपी का मल्टी-थ्रेड का आसान ऐक्सेस, नए Vulkan स्टैंडर्ड को बनाने की प्रेरणा है). Android वेबव्यू में ड्रॉइंग के लिए एक अलग ओएस-लेवल का रेंडर थ्रेड होता है, क्योंकि वेबव्यू को नेटिव ऐप्लिकेशन में एम्बेड किए जाने के तरीके की वजह से होता है. आने वाले समय में दूसरे प्लैटफ़ॉर्म पर भी ऐसा थ्रेड होगा.
डिसप्ले कंपोज़िटर किसी दूसरे थ्रेड पर है, क्योंकि इसका हर समय रिस्पॉन्सिव होना चाहिए. साथ ही, जीपीयू के मुख्य थ्रेड पर धीमे ट्रैफ़िक के किसी भी सोर्स को ब्लॉक नहीं करना चाहिए. जीपीयू के मुख्य थ्रेड पर ट्रैफ़िक धीमा होने की एक वजह, नॉन-Chromium कोड में कॉल करना है. जैसे, वेंडर के हिसाब से जीपीयू ड्राइवर, जो धीमे हो सकते हैं और जिनका अंदाज़ा लगाना मुश्किल हो सकता है.
कॉम्पोनेंट का स्ट्रक्चर
हर रेंडर प्रोसेस के मुख्य या कंपोज़िटर थ्रेड में, ऐसे लॉजिकल सॉफ़्टवेयर कॉम्पोनेंट होते हैं जो एक-दूसरे से स्ट्रक्चर्ड तरीके से इंटरैक्ट करते हैं.
प्रोसेस के मुख्य थ्रेड कॉम्पोनेंट को रेंडर करना
- ब्लिंक रेंडरर:
- लोकल फ़्रेम ट्री फ़्रैगमेंट, लोकल फ़्रेम के ट्री और फ़्रेम के अंदर के डीओएम को दिखाता है.
- DOM और Canvas API कॉम्पोनेंट में, इन सभी एपीआई को लागू करने की जानकारी शामिल होती है.
- दस्तावेज़ लाइफ़साइकल रनर, रेंडरिंग पाइपलाइन के चरणों को तय किए गए चरण तक और तय किए गए चरण तक एक्ज़ीक्यूट करता है.
- इनपुट इवेंट हिट की जांच और डिस्पैच करने वाला कॉम्पोनेंट, हिट की जांच करता है. इससे यह पता चलता है कि किस DOM एलिमेंट को किसी इवेंट से टारगेट किया गया है. साथ ही, यह इनपुट इवेंट डिस्पैच करने वाले एल्गोरिदम और डिफ़ॉल्ट व्यवहार भी चलाता है.
- रेंडरिंग इवेंट लूप शेड्यूलर और रनर यह तय करता है कि इवेंट लूप पर क्या चलाना है और कब चलाना है. यह रेंडर होने के लिए, डिवाइस के डिसप्ले से मैच करने वाली फ़्रीक्वेंसी को शेड्यूल करता है.
लोकल फ़्रेम ट्री के फ़्रैगमेंट के बारे में सोचना थोड़ा मुश्किल है. रीकॉल करें कि फ़्रेम ट्री मुख्य पेज है और उसका चाइल्ड 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>
इन टैब के लिए प्रोसेस, थ्रेड, और कॉम्पोनेंट का स्ट्रक्चर इस तरह दिखेगा:
चलिए, अब रेंडरिंग के चार मुख्य कामों में से हर एक के एक उदाहरण के बारे में जानते हैं. ये काम आपको याद हो सकते हैं:
- कॉन्टेंट को स्क्रीन पर पिक्सल में रेंडर करें.
- एक स्थिति से दूसरी स्थिति में कॉन्टेंट पर विज़ुअल इफ़ेक्ट को ऐनिमेट करें.
- इनपुट के जवाब में स्क्रोल करें.
- रूट सही जगहों पर असरदार तरीके से इनपुट करें, ताकि डेवलपर स्क्रिप्ट और अन्य सबसिस्टम जवाब दे सकें.
पहले टैब के लिए बदले गए डीओएम को रेंडर करने के लिए:
- एक डेवलपर स्क्रिप्ट, foo.com की रेंडर प्रोसेस में DOM को बदल देती है.
- ब्लिंक रेंडरर, कंपोज़िटर को बताता है कि उसे रेंडर करने की ज़रूरत है.
- कंपोज़िटर विज़ से कहता है कि उसे रेंडर करने की ज़रूरत है.
- Viz, रेंडर की शुरुआत के बारे में कंपोज़िटर को वापस सिग्नल देता है.
- कंपोज़िटर, स्टार्ट सिग्नल को ब्लिंक रेंडरर पर फ़ॉरवर्ड करता है.
- मुख्य थ्रेड इवेंट लूप रनर, दस्तावेज़ का लाइफ़साइकल चलाता है.
- मुख्य थ्रेड, कंपोज़िटर थ्रेड को नतीजा भेजता है.
- कंपोज़िटर इवेंट लूप रनर, कंपोज़िटिंग लाइफ़साइकल चलाता है.
- रास्टर के लिए, किसी भी रास्टर टास्क को Viz पर भेजा जाता है. इनमें से एक से ज़्यादा टास्क होते हैं.
- जीपीयू पर Viz रास्टर कॉन्टेंट.
- विज़ ने रास्टर टास्क पूरा होने की जानकारी दी. ध्यान दें: Chromium अक्सर रास्टर के पूरा होने का इंतज़ार नहीं करता. इसके बजाय, वह सिंक टोकन का इस्तेमाल करता है. इसे 15वें चरण के पूरा होने से पहले, रास्टर टास्क की मदद से हल करना होता है.
- Viz को एक कंपोज़िटर फ़्रेम भेजा गया है.
- Viz, foo.com की रेंडर प्रोसेस, bar.com iframe को रेंडर करने की प्रोसेस, और ब्राउज़र यूज़र इंटरफ़ेस (यूआई) के लिए कंपोज़िटर फ़्रेम को इकट्ठा करता है.
- विज़ ने ड्रॉ शेड्यूल किया.
- Viz एग्रीगेट किए गए कंपोज़िटर फ़्रेम को स्क्रीन पर ड्रॉ करता है.
दूसरे टैब पर सीएसएस ट्रांसफ़ॉर्म ट्रांज़िशन को ऐनिमेट करने के लिए:
- bar.com रेंडर प्रोसेस के लिए कंपोज़िटर थ्रेड, मौजूदा प्रॉपर्टी ट्री को म्यूट करके अपने कंपोज़िटर इवेंट लूप में किसी ऐनिमेशन को टिक करता है. इसके बाद, कंपोज़िटर लाइफ़साइकल को फिर से चलाया जाता है. (रास्टर और डिकोड करने वाले टास्क हो सकते हैं, लेकिन उन्हें यहां नहीं दिखाया गया है.)
- Viz को एक कंपोज़िटर फ़्रेम भेजा गया है.
- Viz, foo.com रेंडर प्रोसेस, bar.com रेंडर प्रोसेस, और ब्राउज़र के यूज़र इंटरफ़ेस (यूआई) के लिए कंपोज़िटर फ़्रेम को इकट्ठा करता है.
- विज़ ने ड्रॉ शेड्यूल किया.
- Viz एग्रीगेट किए गए कंपोज़िटर फ़्रेम को स्क्रीन पर ड्रॉ करता है.
टैब तीन पर वेब पेज को स्क्रोल करने के लिए:
inputइवेंट (माउस, टच या कीबोर्ड) का क्रम, ब्राउज़र प्रोसेस में आता है.- हर इवेंट को baz.com की रेंडर प्रोसेस कंपोज़िटर थ्रेड पर रूट किया जाता है.
- कंपोज़िटर तय करता है कि मुख्य थ्रेड को इवेंट के बारे में जानने की ज़रूरत है या नहीं.
- अगर ज़रूरी हो, तो इवेंट को मुख्य थ्रेड पर भेजा जाता है.
- मुख्य थ्रेड,
inputइवेंट लिसनर (pointerdown,touchstar,pointermove,touchmoveयाwheel) को ट्रिगर करता है, ताकि यह देखा जा सके कि लिसनर, इवेंट परpreventDefaultको कॉल करेंगे या नहीं. - मुख्य थ्रेड से पता चलता है कि
preventDefaultको कंपोज़िटर को कॉल किया गया था या नहीं. - अगर ऐसा नहीं होता है, तो इनपुट इवेंट को वापस ब्राउज़र प्रोसेस को भेज दिया जाता है.
- ब्राउज़र प्रोसेस इसे हाल ही के अन्य इवेंट के साथ जोड़कर, इसे स्क्रोल जेस्चर में बदल देती है.
- स्क्रोल जेस्चर baz.com की रेंडर प्रोसेस कंपोज़िटर थ्रेड पर एक बार फिर से भेजा जाता है,
- स्क्रोल वहां लागू किया जाता है और bar.com रेंडर प्रक्रिया के लिए कंपोज़िटर थ्रेड अपने कंपोज़िटर इवेंट लूप में एक ऐनिमेशन पर सही का निशान लगाता है.
इसके बाद, यह प्रॉपर्टी ट्री में स्क्रोल ऑफ़सेट में बदलाव करता है और कंपोज़िटर लाइफ़साइकल को फिर से चलाता है.
यह मुख्य थ्रेड को
scrollइवेंट ट्रिगर करने के लिए भी कहता है (यहां नहीं दिखाया गया है). - Viz को एक कंपोज़िटर फ़्रेम भेजा गया है.
- Viz, foo.com की रेंडर प्रोसेस, bar.com की रेंडर प्रोसेस, और ब्राउज़र के यूज़र इंटरफ़ेस (यूआई) के लिए कंपोज़िटर फ़्रेम को इकट्ठा करता है.
- विज़ ने ड्रॉ शेड्यूल किया.
- Viz एग्रीगेट किए गए कंपोज़िटर फ़्रेम को स्क्रीन पर ड्रॉ करता है.
टैब एक पर iframe #two में हाइपरलिंक पर click इवेंट रूट करने के लिए:
- ब्राउज़र प्रोसेस में
inputइवेंट (माउस, टच या कीबोर्ड) आता है. यह एक अनुमानित हिट जांच करता है, ताकि यह तय किया जा सके कि bar.com iframe रेंडर प्रोसेस को क्लिक मिलना चाहिए और उसे वहां भेज देता है. - bar.com का कंपोज़िटर थ्रेड,
clickइवेंट को bar.com के मुख्य थ्रेड पर ले जाता है और उसे प्रोसेस करने के लिए, रेंडरिंग इवेंट लूप टास्क को शेड्यूल करता है. - bar.com के मुख्य थ्रेड के इनपुट इवेंट प्रोसेसर ने यह पता लगाने के लिए जांच की कि iframe में किस DOM एलिमेंट पर क्लिक किया गया था, यह जांच करता है और स्क्रिप्ट के लिए निगरानी करने के लिए,
clickइवेंट ट्रिगर करता है.preventDefaultनहीं सुनाई दे रहा है, तो वह हाइपरलिंक पर ले जाता है. - हाइपरलिंक के डेस्टिनेशन पेज के लोड होने पर, नई स्थिति रेंडर की जाती है. इस स्थिति में, ऊपर दिए गए "बदले गए DOM को रेंडर करें" उदाहरण जैसे ही तरीके से रेंडर किया जाता है. (बाद के इन बदलावों को यहां नहीं दिखाया गया है.)
नतीजा
ओह, यह तो बहुत सारी जानकारी थी. जैसा कि आपको दिख रहा है, Chromium में रेंडर करना बहुत मुश्किल है! सभी हिस्सों को याद रखने और इंटरनलाइज़ करने में काफ़ी समय लग सकता है, इसलिए अगर आपको यह मुश्किल लग रहा हो, तो परेशान न हों.
सबसे अहम बात यह है कि इसे रेंडर करने की एक आसान प्रोसेस है. इसे मॉड्यूलराइज़ेशन और बारीकियों पर ध्यान देकर, कई सारे कॉम्पोनेंट में बांटा गया है. इसके बाद, इन कॉम्पोनेंट को समानांतर प्रोसेस और थ्रेड में बांटा जाता है, ताकि स्केलेबल परफ़ॉर्मेंस और एक्सटेंसिटी बढ़ाने के अवसरों को बढ़ाया जा सके.
उनमें से हर एक कॉम्पोनेंट, मॉडर्न वेब ऐप्लिकेशन की ज़रूरत के सभी परफ़ॉर्मेंस और सुविधाओं को चालू करने में अहम भूमिका निभाता है. जल्द ही, हम इनमें से हर एक के बारे में गहराई से जानकारी देने के साथ-साथ उनकी अहम भूमिकाओं के बारे में भी बताएंगे.
हालांकि, इससे पहले मैं यह भी बताऊंगी कि इस पोस्ट में बताए गए मुख्य डेटा स्ट्रक्चर (रेंडरिंग पाइपलाइन डायग्राम के किनारों पर नीले रंग से दिखाए गए स्ट्रक्चर), कोड कॉम्पोनेंट की तरह रेंडरिंगNG के लिए कैसे ज़रूरी हैं.
पढ़ने के लिए धन्यवाद. हमारे साथ बने रहें!
यूना क्रावेट्स के चित्र.