जीयूआई आउटपुट एप्लिकेशन से हार्डवेयर स्तर पर कैसे काम करता है?

Question

मैं जीयूआई प्रोग्रामिंग में शामिल हूं और कुछ शोध किया है। अब सब कुछ मेरे लिए स्पष्ट नहीं है। यदि मैं टूलकिट के रूप में जीटीके + का उपयोग करता हूं, तो यह ग्राफिक्स कार्ड के साथ कैसे संवाद करता है?

एक लिनक्स सिस्टम पर मुझे लगता है कि यह जीटीके -> एक्स सर्वर - (ओपनजीएल) -> ग्राफिक्स कार्ड होगा। क्या यह सही है?

मैंने पढ़ा है कि कुछ जीयूआई सीधे ओपनजीएल (उदा। ब्लेंडर 3 डी) खींचते हैं, तो अन्य ऐप्स अपने जीयूआई कैसे आकर्षित करते हैं?

यदि ग्राफिक्स कार्ड के लिए केवल एकमात्र एपीआई (जिसे मैं जानता हूं) डायरेक्ट 3 डी और ओपनजीएल है, तो सॉफ़्टवेयर प्रतिपादन और हार्डवेयर त्वरण के बीच अंतर क्या है?

क्या सॉफ्टवेयर "सॉफ़्टवेयर प्रतिपादन" सीधे ग्राफिक्स कार्ड के फ्रेमबफर को लिख सकता है, ताकि ओपनजीएल छूटा न हो?

पुनश्च: कई सवाल के लिए खेद है, लेकिन मैं वास्तव में यह नहीं मिलता है कैसे है कि सभी काम करता है, हर सवाल का जवाब :)

Answer 1

एक Linux सिस्टम मैं इसे जीटीके होगा लगता है पर के लिए धन्यवाद -> एक्स सर्वर - (ओपनजीएल) -> ग्राफिक्स कार्ड। क्या यह सही है? लिनक्स पर

नहीं। जीटीके +

           /-[ if direct context ]---\ 
        /--> OpenGL >-+---------/       \ 
        /   \-> GLX -+--------------\    \ 
       /      \    \    \ 
GTK+ -+-> cairo >-+---> XRender >--------+----+-> Xlib/xcb >-+-> X server >-+-> Kernel Module >-> GPU 
     \   \–-> pixmap buffer >–/ 
     \       /
     \―---------------------------/ 

मैंने पढ़ा है कि कुछ GUIs सीधे ओपन (जैसे Blender3D) आकर्षित हो जाता है, तो कैसे अन्य एप्लिकेशन उनके GUIs आकर्षित करते हैं?

यह सिर्फ "ब्लेंडर" (कोई पिछला 3 डी नहीं) है। ब्लेंडर की जीयूआई टूलकिट ओपनजीएल का उपयोग केवल बैकएंड के रूप में करती है, हां। लेकिन जीयूआई ओपनजीएल का उपयोग करके सीधे तैयार नहीं किया जाता है, जो कि काम करने के लिए बोझिल होगा (ओपनजीएल कॉल का उपयोग करके प्रत्येक बटन को खींचें। ब्लेंडर का अपना टूलकिट है। जीटीके + एक और टूलकिट है लेकिन ब्लेंडर से बंधे नहीं है (वास्तव में, एक मेरी पालतू परियोजनाओं में से ब्लेंडर की जीयूआई टूलकिट निकालने जा रही है, ताकि इसका इस्तेमाल स्वतंत्र परियोजनाओं में किया जा सके)।

जीटीके + और क्यूटी जैसे टूलकिट अधिकतम पोर्टेबिलिटी के लिए डिज़ाइन किए गए हैं। ब्लेंडर को यह जानने की लक्जरी है कि ओपनजीएल उपलब्ध होगा। जीटीके + या क्यूटी के लिए विकसित एप्स गैर 3 डी सक्षम सिस्टम पर चलने में सक्षम हो सकते हैं, इसलिए जीटीके + और क्यूटी का डिज़ाइन कई बैकएंड पर चलने की इजाजत देता है। जीटीके + अब संस्करण 3 में काहिरा ग्राफिक्स इंजन का उपयोग ग्राफिक्स बैकएंड के रूप में करता है। काहिरा फिर से है अपने स्वयं के बैकएंड, अर्थात् एक सॉफ्टवेयर रास्टराइज़र पिक्समैप्स (पिक्सेल छवियों) में ड्राइंग, या एक अंतर्निहित ग्राफिक्स आर्किटेक्चर के लिए प्रॉक्सिंग ड्राइंग कमांड। मामले में ओ लिनक्स पर एफ काहिरा यह ओपनजीएल या एक्स 11 (कोर और एक्स रेन्डर प्रोटोकॉल एक्सटेंशन) हो सकता है।

यदि ग्राफिक्स कार्ड के लिए केवल एकमात्र एपीआई (जिसे मैं जानता हूं) डायरेक्ट 3 डी और ओपनजीएल है, तो सॉफ़्टवेयर प्रतिपादन और हार्डवेयर त्वरण के बीच अंतर क्या है?

ग्राफिक्स कार्ड पर ओपनजीएल और न ही Direct3D बात न करें। वे ग्राफिक्स कार्ड के ड्राइवरों से बात करते हैं। तो ओपनजीएल और डायरेक्ट 3 डी को छोड़कर, आपके पास विकल्प होगा, जो आप ड्राइवरों से बात करेंगे। लेकिन आप ऐसा क्यों करेंगे? यह थकाऊ है।

इसके अलावा विंडोज़ में आपके पास सामान ड्राइंग के लिए जीडीआई और/या डब्ल्यूपीएफ (विंडोज प्रेजेंटेशन फाउंडेशन) और डायरेक्ट 2 डी है।

लिनक्स पर आपको अच्छी तस्वीरें खींचने के लिए एक्स 11 कोर और एक्सरेंडर एक्सटेंशन प्रोटोकॉल मिलता है।

वृद्धि में एक और एपीआई ओपनवीजी है, जिसका लक्ष्य उन सभी 2 डी ड्राइंग एपीआई को मानकीकृत करना है। और कम से कम लिनक्स ओपनजीएल और ओपनवीजी में लंबे समय तक एकमात्र उपलब्ध अमूर्त ड्राइंग एपीआई बनने के लिए चुना गया है, जिसमें फ्रेमबफर और उपयोगकर्ता इनपुट के प्रबंधन के लिए कुछ विंडोिंग सिस्टम हैं। विकास में वेलैंड (जो डिजाइन मैं पूरी तरह से नापसंद करता हूं) और एक्स 11, जो मुझे लगता है कि बेहतर डिजाइन है (यह एक नेटवर्क उन्मुख प्रणाली है, जो वितरित निष्पादन की अनुमति देता है, जो कुछ मैं भविष्य में बहुत महत्वपूर्ण मानता हूं), लेकिन इसकी आवश्यकता है कुछ "एक्स 12" में पूर्ण ओवरहाल - विरासत क्रॉफ्ट की सफाई, इसे एक संपर्क रंग स्थान में संचालित करें, कनेक्शन को संक्रमण योग्य बनाएं (ताकि आप एक्स सर्वर के बीच क्लाइंट माइग्रेट कर सकें, जो X सत्रों को लॉक करने का एक और अधिक शानदार तरीका प्रदान करेगा लॉकिंग स्क्रीन सेवर का उपयोग करके एक्सेस को अवरुद्ध करने की कोशिश करने के बजाय, सभी कनेक्शनों को कुछ छाया एक्स सर्वर में ले जाकर)।

क्या सॉफ्टवेयर "सॉफ़्टवेयर प्रतिपादन" सीधे ग्राफिक्स कार्ड के फ्रेमबफर को लिख सकता है, ताकि ओपनजीएल छूटा न हो?

आधुनिक ऑपरेटिंग सिस्टम पर नहीं। हालांकि ओएस आपको कुछ फ्रेमबफर एपीआई (/ dev/fb0 पर लिनक्स) के माध्यम से ग्राफिक्स कार्ड के लिए एक सारणी पहुंच प्रदान कर सकता है। हालांकि फ्रेमबफर अप्रबंधित है, इसलिए यदि कोई एक्स सर्वर या वेलैंड चल रहा है, तो उनमें से कोई भी एफबी के प्रबंधन के काम में है, और यह तब आपका कोई व्यवसाय नहीं है।

Answer 2

क्या सॉफ्टवेयर "सॉफ़्टवेयर प्रतिपादन" सीधे ग्राफिक्स कार्ड के फ्रेमबफर को लिख सकता है, ताकि ओपनजीएल छूटा न हो?

काफी या अधिक सटीक नहीं, ड्राइवर पर निर्भर करता है। ऐसा नहीं है कि एक्ससेवर या विंडोज और ओएसएक्स समकक्ष जैसे डिस्प्ले सिस्टम वास्तव में एपीआई का उपयोग करते हैं, बल्कि वर्णन और एपीआई (अधिक सटीक रूप से एक ड्राइवर मॉडल या XServers केस में XAA, EXA, UXA और DRI जैसे कई मॉडलों में से एक है) जिसे डिस्प्ले ड्राइवर को करना है पूरा करते हैं।

इन मॉडलों में परिभाषित नहीं किया गया सब कुछ "सॉफ्टवेयर" में किया जाना चाहिए और सीपीयू पर गणना की जानी चाहिए, इसके अतिरिक्त मॉडल द्वारा परिभाषित कुछ संचालन शायद ड्राइवर द्वारा सीपीयू पर भी गणना की जा सकती हैं।

ओपनजीएल इन मॉडलों से पूरी तरह से अलग मानक होता था और ग्राफिक्स ड्राइवरों को ओएसजी द्वारा लागू ओपनजीएल को लागू करने की आवश्यकता नहीं थी। लेकिन 3 डी ग्राफिक्स के निरंतर एकीकरण और आधुनिक ओएस में अधिक जटिल कंपोजिटिंग के साथ ड्राइवर मॉडल ने ओपनजीएल और डायरेक्टएक्स के समान प्रतिमानों पर भरोसा करना शुरू कर दिया है। उदाहरण के लिए डब्ल्यूडीडीएम हमारी डायरेक्टएक्स 9 समर्थन की आवश्यकता है।