# रेंडरिंग पाइपलाइन > एक पिक्सेल स्क्रीन तक कैसे पहुँचता है — Paint → प्रिमिटिव-वार रेंडरर → OpenGL — और batching क्या है। Source: https://crossfly.dev/hi/docs/concepts/rendering-pipeline — CrossFly documentation. Full docs as one file: https://crossfly.dev/llms-full.txt # रेंडरिंग पाइपलाइन यह समझना कि चित्रण पिक्सेल में कैसे बदलता है, फ्रेमवर्क के कई प्रदर्शन-नियमों को समझा देता है।

## चित्रण की परतें - **`Paint`** वह फ़ेसाड है जिससे आप `onPaint(...)` में चित्रण करते हैं। यह **स्थानीय निर्देशांक**, **clip** और **translation** के हिसाब से सोचता है — और **shaders या OpenGL के बारे में कुछ नहीं जानता**। आप कहते हैं "यह आयत यहाँ बनाओ"; यह त्रिभुजों और GPU कॉल में कैसे बदलता है, वह आपकी समस्या नहीं है। - **`gl` / रेंडरर** — **प्रत्येक प्रिमिटिव के लिए एक विशेषीकृत रेंडरर है** (आयत, गोल आयत, रेखा, टेक्स्ट, छवि…), प्रत्येक मूलतः एक shader। `Paint` सही रेंडरर को सौंप देता है। - **OpenGL** — अंतिम *draw calls*। ## केंद्रीय अवधारणा: batching रेंडरर **एक ही प्रकार** के चित्रणों को batch में समूहित करते हैं ताकि GPU कॉल कम हों। इससे जो नियम निकलता है: > **प्रिमिटिव का प्रकार बदलना पिछले batch को "बंद" कर देता है।** चित्रण का क्रम हमेशा संरक्षित रहता है, पर > प्रकारों के बीच बदलना (आयत → टेक्स्ट → आयत → टेक्स्ट) कई flushes को मजबूर करता है; **एक ही प्रकार की कॉल को > समूहित करना** ही प्रदर्शन देता है। व्यवहार में, भारी कस्टम चित्रण में, सारे आयत एक साथ बनाना और फिर सारे टेक्स्ट, उन्हें आपस में मिलाने से बेहतर परिणाम देता है। ## माँग पर render + पूरे वृक्ष की पुनः-पेंटिंग render मॉडल के दो गुण जो प्रभावित करते हैं कि आप `onPaint` कैसे लिखते हैं: - **माँग पर:** स्क्रीन **केवल तभी पुनः चित्रित होती है जब कोई माँगे** (`repaint()` → `requestRendering()`)। बिना माँग के, कोई नया frame उत्पन्न नहीं होता — बैटरी बचाता है। (इसका threading का पहलू यहाँ है [paint thread](/docs/concepts/the-paint-thread)।) - **कोई *dirty rectangles* नहीं:** जब एक frame होता है, **पूरा दृश्यमान वृक्ष पुनः पेंट होता है**, केवल बदला हुआ हिस्सा नहीं। कोई आंशिक पुनः-पेंटिंग नहीं है। व्यावहारिक परिणाम एक सिद्धांत है: > **`onPaint` को सस्ता रखें।** यह हर रेंडर किए गए frame पर पूरे वृक्ष के लिए चलता है — इसके भीतर वस्तुएँ आवंटित > करना, संसाधन लोड करना या महँगी गणना करना नहीं चाहिए। ## frame कैसे इकट्ठा होता है (उच्च-स्तरीय दृष्टि) हर रेंडर किए गए frame पर, `EventsProcessor` **विंडो के स्टैक** को पेंट करता है (`paintWindows(...)` के ज़रिए): सबसे ऊपर की विंडो सबसे ऊपर, नीचे वाली पीछे (popups पिछली विंडो को दृश्यमान छोड़ देते हैं)। हर दृश्यमान कंपोनेंट को उसका `onPaint(Paint)` मिलता है। ```java // onPaint न्यूनतम और सस्ता: अस्थायी वस्तुएँ पुनः उपयोग करें, स्थानीय coords में बनाएँ (0,0 = ऊपर-बाएँ) @Override public void onPaint(Paint paint) throws Exception { paint.rect(scratch.bounds(0, 0, width, height).fill(bg)); // 'scratch' एक पुनः प्रयुक्त GRect है } ``` ## यह भी देखें - लागू करें: [कस्टम चित्रण](/docs/ui/images-and-graphics/custom-drawing) - आगे: [paint thread](/docs/concepts/the-paint-thread)