यहां आपको पता चलेगा कि रेंडरिंगजीएस कॉम्पोनेंट किस तरह से काम करता है अलग-अलग हिस्सों को सेट अप किया जाता है और रेंडरिंग पाइपलाइन उनके बीच से कैसे फ़्लो करती है.
सबसे ऊंचे लेवल से शुरू करते हुए, रेंडरिंग के काम हैं:
- स्क्रीन पर पिक्सल में कॉन्टेंट रेंडर करें.
- कॉन्टेंट में एक से दूसरी स्थिति में विज़ुअल इफ़ेक्ट ऐनिमेट करें.
- इनपुट के जवाब में स्क्रोल करें.
- सही जगहों पर बेहतर तरीके से रास्ते डालें, ताकि डेवलपर स्क्रिप्ट और दूसरे सबसिस्टम जवाब दे सकें.
रेंडर की जाने वाली सामग्री हर ब्राउज़र टैब के लिए फ़्रेम का एक ट्री है, साथ ही ब्राउज़र इंटरफ़ेस. टचस्क्रीन से आने वाले रॉ इनपुट इवेंट की स्ट्रीम, माउस, कीबोर्ड, और अन्य हार्डवेयर डिवाइस शामिल हैं.
हर फ़्रेम में ये चीज़ें शामिल होती हैं:
- DOM स्थिति
- सीएसएस
- कैनवस
- बाहरी संसाधन, जैसे कि इमेज, वीडियो, फ़ॉन्ट, और SVG
फ़्रेम एक एचटीएमएल दस्तावेज़ होता है. साथ ही, उसका यूआरएल भी होता है. ब्राउज़र टैब में लोड किए गए वेब पेज में एक टॉप-लेवल फ़्रेम होता है, टॉप लेवल दस्तावेज़ में शामिल हर iframe के लिए चाइल्ड फ़्रेम, और उनके रिकर्सिव iframe डिसेंडेंट.
विज़ुअल इफ़ेक्ट एक ग्राफ़िकल ऑपरेशन होता है, जिसे बिट मैप पर लागू किया जाता है, जैसे कि स्क्रोल, ट्रांसफ़ॉर्म, क्लिप, फ़िल्टर, ओपैसिटी या ब्लेंड.
आर्किटेक्चर कॉम्पोनेंट
रेंडरिंग में, इन टास्क को कई स्टेज और कोड में तर्क के साथ बांटा जाता है कॉम्पोनेंट. कॉम्पोनेंट, अलग-अलग सीपीयू प्रोसेस, थ्रेड, और सब-कॉम्पोनेंट का इस्तेमाल करते हैं. हर लक्ष्य को हासिल करने में हर महिला की मदद भरोसेमंद, बेहतरीन परफ़ॉर्मेंस और सभी वेब कॉन्टेंट के लिए एक्सटेंशन की ज़रूरत होती है.
पाइपलाइन का स्ट्रक्चर रेंडर करना
![रेंडरिंग पाइपलाइन का डायग्राम.](https://developer.chrome.com/static/docs/chromium/renderingng-architecture/image/diagram-the-rendering-pi-093c8ed755a54.jpeg?authuser=19&hl=hi)
रेंडर करने की प्रोसेस, एक पाइपलाइन में जारी रहती है. इसमें कई स्टेज और आर्टफ़ैक्ट बनाए जाते हैं ट्रैक करें. हर चरण में कोड होता है. यह एक ऐसा टास्क होता है जिसके बारे में पूरी जानकारी दी गई होती है रेंडरिंग. आर्टफ़ैक्ट, डेटा स्ट्रक्चर हैं जो स्टेज के इनपुट या आउटपुट हों.
चरण इस प्रकार हैं:
- ऐनिमेट करें: समय-समय पर जानकारी देने वाली समयावधि के आधार पर, तय की गई स्टाइल बदलें और समय के साथ प्रॉपर्टी ट्री में बदलाव करें.
- स्टाइल: सीएसएस को डीओएम पर लागू करें और कंप्यूट की गई स्टाइल बनाएं.
- लेआउट: स्क्रीन पर डीओएम एलिमेंट का साइज़ और पोज़िशन तय करते हैं, और नहीं बदला जा सकने वाला फ़्रैगमेंट ट्री बनाएं.
- प्री-पेंट: प्रॉपर्टी ट्री और अमान्य सभी मौजूदा डिसप्ले सूचियों और जीपीयू टेक्सचर टाइल को ज़रूरत के मुताबिक बनाएं.
- स्क्रोल करना: प्रॉपर्टी ट्री में बदलाव करके, दस्तावेज़ों के स्क्रोल ऑफ़सेट और स्क्रोल किए जा सकने वाले डीओएम एलिमेंट को अपडेट करें.
- पेंट: ऐसी डिसप्ले सूची कंप्यूट करें जिसमें डीओएम से जीपीयू टेक्सचर टाइल को रास्टर करने का तरीका बताया गया हो.
- पूरा करें: प्रॉपर्टी ट्री और डिसप्ले सूची को कंपोज़िटर थ्रेड में कॉपी करें.
- लेयराइज़ करें: इंडिपेंडेंट रास्टराइज़ेशन और ऐनिमेशन के लिए, डिसप्ले सूची को कंपोज़िट की गई लेयर वाली सूची में बांटें.
- रास्टर, डिकोड, और पेंट वर्कलेट: ये वर्कलेट, कोड में बदली गई इमेज, और वर्कलेट कोड को पेंट करते हैं जीपीयू टेक्सचर टाइल.
- चालू करें: एक कंपोज़िटर फ़्रेम बनाएं, जो विज़ुअल इफ़ेक्ट के साथ, जीपीयू टाइल को स्क्रीन पर ड्रॉ और जगह देने का तरीका बताता है.
- एग्रीगेट: सभी दिखने वाले कंपोज़िटर फ़्रेम के कंपोज़िटर फ़्रेम को, एक ग्लोबल कंपोज़िटर फ़्रेम में मिलाएं.
- ड्रॉ करें: स्क्रीन पर पिक्सल बनाने के लिए, जीपीयू पर एग्रीगेट किया गया कंपोज़िटर फ़्रेम एक्ज़ीक्यूट करें.
अगर रेंडरिंग पाइपलाइन के स्टेज ज़रूरी नहीं हैं, तो उन्हें स्किप किया जा सकता है. उदाहरण के लिए, विज़ुअल इफ़ेक्ट के ऐनिमेशन और स्क्रोल करने पर, लेआउट स्किप किया जा सकता है, प्री-पेंट किया जा सकता है, और पेंट किया जा सकता है. इसलिए, ऐनिमेशन और स्क्रोल को डायग्राम में पीले और हरे बिंदुओं से मार्क किया जाता है. अगर विज़ुअल इफ़ेक्ट के लिए लेआउट, प्री-पेंट, और पेंट को स्किप किया जा सकता है, उन्हें पूरी तरह कंपोज़िटर थ्रेड पर चलाया जा सकता है और मुख्य थ्रेड को छोड़ा जा सकता है.
ब्राउज़र के यूज़र इंटरफ़ेस (यूआई) की रेंडरिंग सीधे तौर पर यहां नहीं दिखाई गई है, हालांकि, इसे इसी पाइपलाइन के आसान वर्शन के तौर पर माना जा सकता है (और असल में, इसे लागू करने के ज़्यादातर कोड का इस्तेमाल किया जाता है). वीडियो (सीधे तौर पर दिखाया नहीं गया है) आम तौर पर, अलग-अलग कोड के साथ रेंडर होता है, जो फ़्रेम को जीपीयू टेक्सचर टाइल में डीकोड करता है और फिर कंपोज़िटर फ़्रेम्स और ड्रॉ स्टेप में प्लग इन हो जाता है.
प्रोसेस और थ्रेड का स्ट्रक्चर
सीपीयू प्रोसेस
एक से ज़्यादा सीपीयू प्रोसेस का इस्तेमाल करने से, परफ़ॉर्मेंस बेहतर होती है और सुरक्षा को ध्यान में नहीं रखा जाता है साइटों के बीच और ब्राउज़र की स्थिति से, और जीपीयू हार्डवेयर से स्थिरता और सुरक्षा अलग रखना.
- रेंडरिंग की प्रोसेस, किसी एक ही साइट और टैब संयोजन का उपयोग करना चाहिए. रेंडर करने की कई प्रोसेस होती हैं.
- ब्राउज़र प्रोसेस, ब्राउज़र यूज़र इंटरफ़ेस (यूआई) के लिए इनपुट को रेंडर, ऐनिमेट, और रूट करती है (पता बार, टैब के टाइटल, और आइकॉन शामिल हैं) और बाकी बचे सभी रूट सही रेंडर प्रोसेस में इनपुट डालना. ब्राउज़र की एक प्रोसेस होती है.
- Viz प्रोसेस, रेंडर करने की एक से ज़्यादा प्रोसेस से कंपोज़िटिंग को इकट्ठा करती है और ब्राउज़र प्रोसेस पर निर्भर करता है. यह जीपीयू का इस्तेमाल करके ड्रॉ करता है और ड्रॉ करता है. यहां है एक Viz प्रोसेस पूरी करनी होगी.
अलग-अलग साइटें वेबसाइट पर कभी भी दिखती हैं अलग-अलग रेंडर प्रोसेस में होते हैं.
एक ही साइट के कई ब्राउज़र टैब या विंडो, आम तौर पर अलग-अलग रेंडर में जाते हैं ऐसा कर सकता है, जब तक कि टैब एक-दूसरे से जुड़े न हों, जैसे कि खोलें. डेस्कटॉप पर ज़्यादा मेमोरी के दबाव में, Chromium में एक से ज़्यादा टैब लग सकते हैं एक ही साइट से एक ही रेंडर प्रोसेस में भेज दें, भले ही वह संबंधित न हो.
किसी एक ब्राउज़र टैब में, अलग-अलग साइटों के फ़्रेम हमेशा एक-दूसरे से अलग रेंडर प्रोसेस में होते हैं, लेकिन एक ही साइट के फ़्रेम हमेशा एक ही रेंडर प्रोसेस में होते हैं. रेंडरिंग के हिसाब से, कई रेंडर प्रोसेस का अहम फ़ायदा यह है कि क्रॉस-साइट iframe और टैब परफ़ॉर्मेंस अलग-अलग रखते हैं. एक-दूसरे से जुड़ी हुई क्वेरी हैं. इसके अलावा, ऑरिजिन पहले से ज़्यादा आइसोलेशन के लिए ऑप्ट इन कर सकते हैं.
सभी Chromium के लिए, एक ही Viz प्रोसेस है. आम तौर पर, यह प्रोसेस सिर्फ़ एक बनाने के लिए एक जीपीयू और स्क्रीन.
Viz को उसकी प्रोसेस में अलग करना, गड़बड़ियों का सामना करने में स्थिरता के लिए अच्छा है जीपीयू ड्राइवर या हार्डवेयर. यह सिक्योरिटी आइसोलेशन के लिए भी अच्छा है, जो जीपीयू एपीआई के लिए ज़रूरी है, जैसे कि Vulkan और आम तौर पर सुरक्षा.
ब्राउज़र में कई टैब और विंडो हो सकते हैं, इसलिए और उन सभी में ड्रॉ करने के लिए ब्राउज़र यूज़र इंटरफ़ेस (यूआई) पिक्सल होता है, आप सोच सकते हैं: ब्राउज़र की एक ही प्रोसेस क्यों होती है? इसकी वजह यह है कि एक समय पर, उनमें से किसी एक पर ही फ़ोकस किया गया है; असल में, न दिखने वाले ब्राउज़र टैब आम तौर पर बंद हो जाते हैं और अपनी सारी जीपीयू मेमोरी ड्रॉप कर देते हैं. हालांकि, ब्राउज़र के यूज़र इंटरफ़ेस (यूआई) को रेंडर करने वाली जटिल सुविधाओं को तेज़ी से लागू किया जा रहा है रेंडर प्रक्रियाओं में भी ( WebUI) है. ऐसा सिर्फ़ परफ़ॉर्मेंस पर निर्भर न करने की वजह से नहीं किया गया है. यह भी ज़रूरी है कि इसे Chromium के वेब रेंडरिंग इंजन का आसानी से इस्तेमाल करने का फ़ायदा मिले.
पुराने Android डिवाइसों पर, वेबव्यू में इस्तेमाल किए जाने पर रेंडर और ब्राउज़र प्रोसेस शेयर की जाती है (यह आम तौर पर, Android पर Chromium पर लागू नहीं होता, सिर्फ़ वेबव्यू पर लागू होता है). वेबव्यू पर, एम्बेड करने वाले ऐप्लिकेशन के साथ ब्राउज़र प्रोसेस को भी शेयर किया जाता है, और वेबव्यू में सिर्फ़ एक रेंडर प्रोसेस होती है.
कभी-कभी सुरक्षित वीडियो कॉन्टेंट को डिकोड करने के लिए, एक काम की तरीका भी इस्तेमाल की जाती है. यह प्रोसेस पिछले डायग्राम में नहीं दिखाई गई है.
बातचीत के थ्रेड
Thread की मदद से, धीमे टास्क काम करने के बावजूद, परफ़ॉर्मेंस को अलग-अलग और बेहतर तरीके से लागू किया जा सकता है. पाइपलाइन समानांतराइज़ेशन और मल्टीपल बफ़रिंग पर ध्यान दिया जा सकता है.
- मुख्य थ्रेड, स्क्रिप्ट, रेंडरिंग इवेंट लूप, दस्तावेज़ का लाइफ़साइकल,
हिट टेस्टिंग, स्क्रिप्ट इवेंट डिस्पैच, और एचटीएमएल, सीएसएस, और अन्य डेटा फ़ॉर्मैट को पार्स करना.
- मुख्य थ्रेड के हेल्पर, इमेज बिटमैप और ब्लॉब बनाने जैसे काम करते हैं, जिन्हें कोड में बदलने या डिकोड करने की ज़रूरत होती है.
- वेब वर्कर रन स्क्रिप्ट और ऑफ़स्क्रीन कैनवास के लिए रेंडरिंग इवेंट लूप है.
- कंपोज़िटर थ्रेड, इनपुट इवेंट को प्रोसेस करता है,
वेब कॉन्टेंट को स्क्रोल करके और ऐनिमेशन करता है,
वेब कॉन्टेंट की सबसे बेहतरीन लेयराइज़ेशन का पता लगाता है.
और इमेज डीकोड, वर्कलेट और रास्टर टास्क को पेंट करें.
- कंपोज़िटर थ्रेड हेल्पर, विज़ रास्टर टास्क को कोऑर्डिनेट करते हैं, साथ ही, इमेज डिकोड करने के टास्क, पेंट वर्कलेट, और फ़ॉलबैक रास्टर एक्ज़ीक्यूट कर सकते हैं.
- मीडिया, डीमक्सर या ऑडियो आउटपुट थ्रेड डिकोड करना, वीडियो और ऑडियो स्ट्रीम प्रोसेस करने और उन्हें सिंक करने में मदद मिलती है. (याद रखें कि वीडियो, रेंडरिंग की मुख्य पाइपलाइन के साथ-साथ चलता है.)
मुख्य और कंपोज़िटर थ्रेड को अलग-अलग करना परफ़ॉर्मेंस आइसोलेशन ऐनिमेशन और मुख्य थ्रेड के काम से स्क्रोल किया जा सकता है.
हर रेंडर की प्रोसेस में सिर्फ़ एक मुख्य थ्रेड होता है. भले ही एक ही साइट के कई टैब या फ़्रेम एक ही प्रक्रिया में खत्म हो जाएं. हालांकि, अलग-अलग ब्राउज़र एपीआई में किए गए काम से परफ़ॉर्मेंस आइसोलेशन होती है. उदाहरण के लिए, कैनवस एपीआई में इमेज बिटमैप और ब्लॉब की जनरेशन मुख्य थ्रेड के हेल्पर थ्रेड में चलती है.
इसी तरह, हर रेंडर प्रोसेस में सिर्फ़ एक कंपोज़िटर थ्रेड होता है. आम तौर पर यह समस्या नहीं होती कि सिर्फ़ एक ही समस्या है. कंपोज़िटर थ्रेड पर बहुत महंगे ऑपरेशन होते थे को या तो कंपोज़िटर वर्कर थ्रेड या Viz प्रोसेस के लिए असाइन किया जाता है, यह काम इनपुट रूटिंग, स्क्रोलिंग या ऐनिमेशन के साथ किया जा सकता है. कंपोज़िटर वर्कर थ्रेड, Viz प्रोसेस में चलाए जाने वाले टास्क को कोऑर्डिनेट करते हैं, हालांकि, हर जगह जीपीयू से तेज़ी आती है Gmail के कंट्रोल से बाहर की वजहों से फ़ेल हो सकता है. जैसे कि ड्राइवर की गड़बड़ियां. इन स्थितियों में वर्कर थ्रेड, सीपीयू पर फ़ॉलबैक मोड में काम करता है.
कंपोज़िटर वर्कर थ्रेड की संख्या, डिवाइस की क्षमता पर निर्भर करती है. उदाहरण के लिए, डेस्कटॉप पर आम तौर पर ज़्यादा थ्रेड इस्तेमाल किए जाएंगे, क्योंकि उनमें ज़्यादा सीपीयू कोर होते हैं और मोबाइल डिवाइसों की तुलना में उनकी बैटरी कम होती है. यह इसका एक उदाहरण है स्केल अप करना और स्केल करना शामिल है.
रेंडर प्रोसेस की थ्रेडिंग आर्किटेक्चर, तीन अलग-अलग तरह के ऐप्लिकेशन का एक ऐप्लिकेशन है ऑप्टिमाइज़ेशन पैटर्न:
- हेल्पर थ्रेड: लंबे समय तक चलने वाले सबटास्क को दूसरे थ्रेड में बंद करें, ताकि उन्हें बनाए रखा जा सके एक साथ कई अनुरोधों पर प्रतिक्रिया देने वाला पैरंट थ्रेड. मुख्य थ्रेड हेल्पर और कंपोज़िटर हेल्पर थ्रेड इस तकनीक के अच्छे उदाहरण हैं.
- एक से ज़्यादा बफ़र करना: नया कॉन्टेंट रेंडर करते समय, पहले रेंडर किया गया कॉन्टेंट दिखाने के लिए, ताकि रेंडरिंग में लगने वाला समय. कंपोज़िटर थ्रेड इस तकनीक का इस्तेमाल करता है.
- पाइपलाइन पैरललाइज़ेशन: रेंडरिंग पाइपलाइन को एक से ज़्यादा जगहों पर चलाएं साथ-साथ स्क्रोलिंग और ऐनिमेशन तेज़ी से किए जा सकते हैं; भले ही, किसी मुख्य थ्रेड को रेंडर करने के लिए अपडेट हो रहा है. स्क्रोल और ऐनिमेशन, साथ-साथ चलेगा.
ब्राउज़र प्रक्रिया
- रेंडर और कंपोज़िटिंग थ्रेड, ब्राउज़र यूज़र इंटरफ़ेस (यूआई) में इनपुट का जवाब देता है, दूसरे इनपुट को सही रेंडर प्रोसेस पर ले जाता है; ब्राउज़र यूज़र इंटरफ़ेस (यूआई) को लेआउट और पेंट करता है.
- रेंडर और कंपोज़िटिंग थ्रेड हेल्पर इमेज डिकोड करने के टास्क और फ़ॉलबैक रास्टर या डिकोड करना.
ब्राउज़र प्रोसेस रेंडर और कंपोज़िटिंग थ्रेड एक जैसे हैं के काम करने के तरीके और उनके काम करने के तरीके पर ज़्यादा ध्यान देते हैं. इसे छोड़कर, मुख्य थ्रेड और कंपोज़िटर थ्रेड को एक साथ जोड़ दिया जाता है. इस मामले में सिर्फ़ एक थ्रेड की ज़रूरत है, क्योंकि मुख्य थ्रेड के लंबे टास्क से परफ़ॉर्मेंस आइसोलेशन, क्योंकि इन्हें डिज़ाइन नहीं किया गया है.
विज़ प्रोसेस
- 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>
इन टैब की प्रोसेस, थ्रेड, और कॉम्पोनेंट का स्ट्रक्चर इस तरह दिखता है:
आइए, रेंडरिंग के चार मुख्य कामों में से हर एक का उदाहरण देखते हैं. रिमाइंडर:
- कॉन्टेंट को स्क्रीन पर पिक्सल में रेंडर करना.
- कॉन्टेंट में एक से दूसरी स्थिति में विज़ुअल इफ़ेक्ट एनिमेटेड करें.
- इनपुट के जवाब में स्क्रोल करें.
- सही जगहों पर बेहतर तरीके से रूट भेजें, ताकि डेवलपर स्क्रिप्ट और दूसरे सबसिस्टम जवाब दे सकें.
टैब पहले के लिए बदले गए DOM को रेंडर करने के लिए:
- डेवलपर स्क्रिप्ट, foo.com के लिए रेंडर करने की प्रोसेस में DOM को बदल देती है.
- ब्लिंक रेंडरर, कंपोज़िटर को बताता है कि उसे रेंडर होने की ज़रूरत है.
- कंपोज़िटर विज़ को बताता है कि उसे रेंडर होने की ज़रूरत है.
- Viz, रेंडर की शुरुआत कंपोज़िटर को वापस शुरू करने का सिग्नल देता है.
- कंपोज़िटर, स्टार्ट सिग्नल को ब्लिंक रेंडरर पर फ़ॉरवर्ड करता है.
- मुख्य थ्रेड इवेंट लूप रनर, दस्तावेज़ का लाइफ़साइकल चलाता है.
- मुख्य थ्रेड, नतीजे को कंपोज़िटर थ्रेड को भेजती है.
- कंपोज़िटर इवेंट लूप रनर, कंपोज़िटिंग लाइफ़साइकल चलाता है.
- किसी भी रास्टर टास्क को रास्टर के लिए विज़ को भेजा जाता है (अक्सर इनमें से एक से ज़्यादा टास्क होते हैं).
- जीपीयू पर विज़ रैस्टर कॉन्टेंट.
- विज़, रास्टर टास्क पूरा होने के बारे में स्वीकार करते हैं. ध्यान दें: Chromium अक्सर रास्टर के पूरा होने का इंतज़ार नहीं करता, और इसके बजाय सिंक टोकन जिसे हल करना ज़रूरी है रास्टर टास्क के हिसाब से, 15वें चरण को पूरा करने से पहले.
- एक कंपोज़िटर फ़्रेम, Viz को भेजा गया.
- Viz, foo.com रेंडर प्रोसेस के लिए कंपोज़िटर फ़्रेम को एग्रीगेट करता है, Bar.com iframe रेंडर होने की प्रोसेस और ब्राउज़र यूज़र इंटरफ़ेस (यूआई) पर स्विच करता है.
- विज़ ड्रॉ शेड्यूल करता है.
- विज़, एग्रीगेट किए गए कंपोज़िटर फ़्रेम को स्क्रीन पर ड्रॉ करता है.
सीएसएस ट्रांसफ़ॉर्म ट्रांज़िशन को टैब दो पर ऐनिमेट करने के लिए:
- Bar.com रेंडर प्रोसेस के लिए कंपोज़िटर थ्रेड में एक ऐनिमेशन दिखता है मौजूदा प्रॉपर्टी ट्री में बदलाव करके, अपने कंपोज़िटर इवेंट लूप में. इसके बाद, कंपोज़िटर का लाइफ़साइकल फिर से चलता है. (रास्टर और डिकोड करने वाले टास्क, हो सकते हैं, लेकिन उन्हें यहां नहीं दिखाया जाता.)
- एक कंपोज़िटर फ़्रेम, Viz को भेजा गया.
- Viz, foo.com रेंडर प्रोसेस, बार.com रेंडर प्रोसेस, और ब्राउज़र यूज़र इंटरफ़ेस (यूआई) के लिए कंपोज़िटर फ़्रेम को एग्रीगेट करता है.
- विज़ ड्रॉ शेड्यूल करता है.
- विज़, एग्रीगेट किए गए कंपोज़िटर फ़्रेम को स्क्रीन पर ड्रॉ करता है.
टैब तीन पर वेब पेज को स्क्रोल करने के लिए:
- ब्राउज़र प्रोसेस में
input
इवेंट का क्रम (माउस, टच या कीबोर्ड) आता है. - हर इवेंट को baz.com के रेंडर प्रोसेस कंपोज़िटर थ्रेड में रूट किया जाता है.
- कंपोज़िटर यह तय करता है कि मुख्य थ्रेड को इवेंट के बारे में जानने की ज़रूरत है या नहीं.
- ज़रूरी होने पर, इवेंट को मुख्य थ्रेड पर भेजा जाता है.
- मुख्य थ्रेड,
input
इवेंट लिसनर को ट्रिगर करता है (pointerdown
,touchstar
,pointermove
,touchmove
याwheel
) यह देखने के लिए कि क्या श्रोता इवेंट परpreventDefault
को कॉल करेंगे. - मुख्य थ्रेड यह बताती है कि
preventDefault
को कंपोज़िटर को कॉल किया गया था या नहीं. - अगर ऐसा नहीं है, तो इनपुट इवेंट को वापस ब्राउज़र प्रोसेस में भेजा जाएगा.
- ब्राउज़र प्रोसेस उसे हाल ही के अन्य इवेंट के साथ मिला कर, उसे स्क्रोल जेस्चर में बदल देती है.
- स्क्रोल जेस्चर को एक बार फिर baz.com के रेंडर प्रोसेस कंपोज़िटर थ्रेड पर भेजा जाता है,
- स्क्रोल वहां लागू होता है और bar.com के लिए कंपोज़िटर थ्रेड लागू होती है
रेंडर प्रोसेस के कंपोज़िटर इवेंट लूप में ऐनिमेशन टिक होता है.
इसके बाद यह प्रॉपर्टी ट्री में स्क्रोल ऑफ़सेट को बदल देता है और कंपोज़िटर के लाइफ़साइकल को फिर से चलाता है.
यह मुख्य थ्रेड को
scroll
इवेंट ट्रिगर करने के लिए भी कहता है (यहां नहीं दिखाया गया है). - एक कंपोज़िटर फ़्रेम, Viz को भेजा गया.
- Viz, foo.com रेंडर प्रोसेस के लिए कंपोज़िटर फ़्रेम को एग्रीगेट करता है, बार.com रेंडर प्रोसेस, और ब्राउज़र यूज़र इंटरफ़ेस (यूआई) की इमेज शामिल करें.
- विज़ ड्रॉ शेड्यूल करता है.
- विज़, एग्रीगेट किए गए कंपोज़िटर फ़्रेम को स्क्रीन पर ड्रॉ करता है.
टैब पहले पर iframe #two में हाइपरलिंक पर click
इवेंट को रूट करने के लिए:
- ब्राउज़र प्रोसेस में
input
इवेंट (माउस, टच या कीबोर्ड) आता है. यह अनुमानित हिट टेस्ट करता है ताकि यह तय किया जा सके कि bar.com iframe रेंडर होने की प्रोसेस को क्लिक मिलना चाहिए और उसे वहां भेज दिया जाता है. - Bar.com का कंपोज़िटर थ्रेड,
click
इवेंट को मुख्य थ्रेड पर रूट करता है Bar.com के लिए काम करता है और इसे प्रोसेस करने के लिए रेंडरिंग इवेंट लूप टास्क को शेड्यूल करता है. - Bar.com के मुख्य थ्रेड का इनपुट इवेंट प्रोसेसर हिट यह तय करने के लिए टेस्ट करता है कि
iframe में मौजूद DOM एलिमेंट पर क्लिक किया गया है और स्क्रिप्ट की निगरानी के लिए
click
इवेंट ट्रिगर करता है.preventDefault
सुनाई नहीं दे रहा, इसलिए यह हाइपरलिंक पर ले जाती है. - हाइपरलिंक के डेस्टिनेशन पेज के लोड होने पर, एक नई स्थिति दिखाई जाती है, "रेंडरिंग का बदला गया DOM" जैसे चरणों के साथ पिछला उदाहरण. (इन बदलावों को यहां नहीं दिखाया गया है.)
खाना पैक कराकर ले जाने की सुविधा
रेंडरिंग के काम करने के तरीके को याद रखने और उसे अपने हिसाब से बनाने में बहुत समय लग सकता है.
सबसे ज़रूरी बात यह है कि रेंडरिंग पाइपलाइन को मॉड्यूलराइज़ेशन और बारीकियों पर ध्यान देने की सुविधा को कई अपने-आप में पूरे कॉम्पोनेंट. इसके बाद, इन कॉम्पोनेंट को पैरलल में बांट दिया गया है प्रोसेस और थ्रेड को ऑप्टिमाइज़ किया जा सकता है. बेहतर परफ़ॉर्मेंस साथ ही, इस्तेमाल करने के बेहतरीन अवसर उपलब्ध होने चाहिए.
हर कॉम्पोनेंट, परफ़ॉर्मेंस और सुविधाओं को चालू करने में अहम भूमिका निभाता है मॉडर्न वेब ऐप्लिकेशन उपलब्ध हैं.
मुख्य डेटा स्ट्रक्चर के बारे में पढ़ना जारी रखें, जो रेस्पॉन्ड करने के लिए, कोड कॉम्पोनेंट के बराबर ही ज़रूरी हैं.
यूना क्रवेट्स के इलस्ट्रेशन.