GPU पर तेज़ और स्पष्ट टेक्स्ट रेंडरिंग

• टेक्स्ट रेंडरिंग की गुणवत्ता समस्याओं, खासकर SDF (distance field) आधारित तरीकों की सीमाओं को हल करने के लिए एक नई real-time vector rendering तकनीक प्रस्तावित की गई है
• glyphs (अक्षरों) को vector curves के रूप में सीधे GPU पर भेजकर real-time rasterization किया जाता है, जिससे असीमित resolution और कम memory उपयोग हासिल होता है
• texture atlas और temporal accumulation तकनीकों का उपयोग करके उच्च anti-aliasing गुणवत्ता और प्रभावी caching हासिल की जाती है
• यह विभिन्न subpixel संरचनाओं (जैसे OLED, LCD आदि) के अनुसार अनुकूलित किया जा सकता है, जिससे fringing (रंग फैलाव) के बिना मुलायम और स्पष्ट परिणाम मिलते हैं
• real-time text, UI, games आदि में उच्च-गुणवत्ता font rendering के लिए यह एक सरल लेकिन अत्यधिक scalable approach प्रस्तुत करता है

---

परिचय: टेक्स्ट रेंडरिंग की चुनौती

• real-time text rendering में aliasing (सीढ़ीदार किनारे), बड़े texture, build time, zoom in/out, smooth movement जैसी कई समस्याएँ होती हैं
• प्रचलित Multi-Channel Signed Distance Fields (SDFs) तरीके में गुणवत्ता और लचीलेपन, दोनों की सीमाएँ थीं
• हाल के OLED monitors की non-standard subpixel संरचना और fringing समस्या ने subpixel anti-aliasing को ध्यान में रखते हुए एक नया approach विकसित करने की प्रेरणा दी

मौजूदा SDF तरीके की सीमाएँ

गुणवत्ता

• SDF तरीके में बारीक डिटेल या पतली strokes वाले fonts में गुणवत्ता गिरने और जानकारी खोने की समस्या आती है
• resolution बढ़ाए बिना कुछ glyphs में artifacts बने रहते हैं

atlas का आकार

• SDF को पहले offline बनाकर atlas में संग्रहीत किया जाता है, लेकिन बहुत सारे glyphs या CJK (चीनी, जापानी, कोरियाई) fonts के मामले में इसका आकार व्यावहारिक रूप से असंभव स्तर तक बढ़ सकता है
• एक साथ कई fonts उपयोग करने पर memory खपत और streaming bandwidth का बोझ बढ़ जाता है

लचीलापन और सरलता

• SDF एक मध्यवर्ती चरण होने के कारण source data से final output तक का पूरा flow जटिल हो जाता है
• real-time या dynamic vector images को सीधे उपयोग या संपादित करने में बड़ी बाधाएँ आती हैं

नया तरीका: vector curves की real-time rasterization

• पहले से texture बनाने के बजाय, स्क्रीन पर वास्तव में दिख रहे glyphs की vector curve data (जैसे Bezier curves) सीधे GPU पर भेजी जाती है और वहीं rasterize किया जाता है
• atlas texture में जरूरत के अनुसार ही glyphs रखे जाते हैं, और उपयोग की आवृत्ति के आधार पर उन्हें बनाए रखा या हटाया जाता है
• glyphs जब तक स्क्रीन पर रहते हैं, तब तक sample accumulation (temporal accumulation) के जरिए बेहद उच्च-गुणवत्ता और अधिक smooth anti-aliased परिणाम प्राप्त किए जाते हैं
• चूँकि प्रोसेसिंग हमेशा vector-based रहती है, इसलिए resolution की कोई सीमा नहीं होती और परिणाम स्पष्ट बने रहते हैं

font curve data की प्रोसेसिंग

• FreeType जैसी open source libraries से विभिन्न font formats पढ़कर glyphs की curve जानकारी निकाली जाती है
• glyphs को lines, quadratic/cubic Bezier curves के रूप में parse किया जाता है, और GPU shader में प्रोसेसिंग सरल करने के लिए सभी curves को quadratic Bezier curves में बदला जाता है
  • lines में एक मध्य control point जोड़कर उन्हें quadratic curves में बदला जाता है
  • cubic curves को 2 विभाजित quadratic curves में बदला जाता है

coverage (pixel के भीतर भराव) की गणना

• हर pixel पर क्षैतिज दिशा (ray) में curve के साथ intersection निकाला जाता है, और winding number (संचयी intersection count) के आधार पर अंदर/बाहर का निर्धारण किया जाता है
• सैकड़ों samples (n बार के accumulated samples) को जोड़ा जाता है, और कुछ सूक्ष्म त्रुटियाँ अंतिम परिणाम पर लगभग असर नहीं डालतीं
• sample point placement (quasirandom sequence) तकनीक के जरिए हर frame में अलग-अलग स्थानों से परिणामों को accumulate किया जाता है

curve access का optimization

• glyphs को horizontal bands में विभाजित किया जाता है, और हर band के लिए केवल संबंधित curves की जाँच कर computation कम किया जाता है
• thread arrangement और band-आधारित iteration के जरिए GPU पर bulk computation efficiency को अधिकतम किया जाता है

atlas packing और management

• atlas (shared texture) में हर glyph image को allocate करके manage किया जाता है
  • जो glyph मौजूद नहीं होता, उसके लिए नई जगह allocate करके rasterize किया जाता है; जो पहले से मौजूद है, उसे reuse किया जाता है
  • ध्यान रहे, एक ही glyph के लिए भी subpixel position और size के आधार पर अलग versions की आवश्यकता हो सकती है
• Z-Order Packing (जैसे Morton code) के जरिए 1D bitset और 2D space के बीच प्रभावी packing लागू की जाती है
  • Latin scripts के लिए vertical आधार, Arabic scripts के लिए horizontal आधार जैसे भाषाई संरचना के अनुसार लचीला उपयोग संभव है
• जब किसी glyph की जरूरत नहीं रहती, तो atlas space को फिर से allocate करके उपयोग किया जाता है

temporal accumulation

• glyph caching और sample accumulation के जरिए, दिखने के तुरंत बाद तेज़ी से उच्च-गुणवत्ता samples जुटाए जाते हैं, और फिर आगे के frames में उन्हें और परिष्कृत किया जाता है
  • पहले frame में 8 samples/pixel, उसके बाद धीरे-धीरे sample count घटता है, और अधिकतम 512 accumulations तक जाता है
• मुलायम glyph rendering और resource optimization, दोनों साथ हासिल किए जाते हैं

subpixel anti-aliasing और fringing की रोकथाम

• subpixel (जैसे RGB के प्रत्येक घटक को sample मानकर) स्तर पर rendering area बाँटकर क्षैतिज resolution बढ़ाने जैसा प्रभाव हासिल किया जाता है
  • LCD की मानक संरचना, OLED/WOLED सहित विभिन्न layouts का समर्थन
  • fringing (रंग फैलाव) के बिना smooth effect निर्धारित किया जा सकता है
• subpixel samples को overlapping रूप से व्यवस्थित करने पर वास्तविक monitor के light blending effect को भी दर्शाया जा सकता है
• pixel boundaries या hinting के बिना भी प्राकृतिक और स्पष्ट output संभव है

display-विशिष्ट subpixel संरचना approach का महत्व

• यदि monitor की subpixel arrangement जानकारी को programmatically जाँचा जा सके, तो कहीं अधिक परिष्कृत rendering संभव हो जाती है
• यह रेखांकित किया गया है कि यह hardware की सीमा नहीं, बल्कि software processing की समस्या है

निष्कर्ष और उपयोग की संभावनाएँ

• अच्छी text rendering का कुल usability और service quality पर बड़ा प्रभाव पड़ता है
• खासकर UI/games में उच्च-गुणवत्ता font प्रस्तुति product experience में बड़ा अंतर ला सकती है
• यह सरलता, scalability, उच्च गुणवत्ता और लचीलेपन के सिद्धांतों को साकार करने वाली कार्य-रचना है
• open source implementation और विभिन्न subpixel layouts के समर्थन के कारण यह वास्तविक उद्योग/production उपयोग के लिए बेहद उपयुक्त है

---

[GN⁺]

Hacker News राय

• यह पोस्ट लिखने वाले के रूप में, मुझे अंदाज़ा नहीं था कि यह लेख इतना चर्चा में आ जाएगा। दिलचस्प बातचीत में शामिल होने वाले सभी लोगों का धन्यवाद
• पहले वीडियो में italic "j" का बिंदु गायब होने की वजह पर सवाल
• यह राय कि subpixel font rendering पठनीयता के लिए बहुत महत्वपूर्ण है। लेकिन जैसा लेखक ने बताया, मौजूदा display standards में सटीक pixel layout specification नहीं मिल पाती, यह अफसोस की बात है
• मेरा मानना है कि यह सिर्फ standard resolution displays पर ज़रूरी है। सच कहें तो यह अनिवार्य नहीं, बल्कि हो तो अच्छा है। अब Retina-स्तर के displays आम हो गए हैं, इसलिए ऐसा माहौल बन गया है जहाँ subpixel rendering की खास ज़रूरत नहीं रही। बल्कि यह LCD दौर में आई एक अस्थायी innovation थी और अब कुछ पुरानी लगती है। screenshot का subpixel layout पर निर्भर होना, bitmap को enlarge न कर पाना जैसे काफ़ी side effects भी हैं। इसलिए मुझे लगता है कि Apple ने macOS से इस तरीके को पूरी तरह हटा दिया
• यह इशारा कि DisplayID जैसे standards इस तरह की layout जानकारी देने के लिए डिज़ाइन किए गए थे। बस manufacturers इसे ठीक से implement नहीं करते या DB में store नहीं होता; लेकिन अगर कोई display model काफ़ी लोकप्रिय हो, तो hardware info DB में उसे दर्ज करके इस्तेमाल किया जा सकता है। DisplayID wiki देखें
• इस बात का अफसोस कि हम दशकों से subpixel structures की विविधता जानते थे, और यह सराहना कि मूल लेख ने इसे अच्छी तरह व्यवस्थित किया। साथ ही ‘subpixel zoo’ नाम से मशहूर उदाहरण पेज साझा किया गया subpixel zoo
• मुझे नहीं लगता कि इसे ‘त्रासदी’ कहना ठीक है। अगर हर OS बस पहले के Windows ClearType tuner की तरह per-display fine tuning का विकल्प दे दे, तो वही काफ़ी होगा। monitor जब जानकारी ग़लत report करे, उसके लिए user settings को याद रखने की भी ज़रूरत है
• यह राय कि subpixel rendering ज़्यादातर भाषाओं में अनिवार्य नहीं है। anti-aliasing के बिना bitmap fonts या hinted vector fonts भी आराम से पढ़े जा सकते हैं। लेकिन Chinese characters या Japanese जैसी जटिल लिपियों वाली भाषाओं में इसका महत्व थोड़ा ज़्यादा है
• GTK4 ने GPU-केंद्रित rendering पर जाते हुए RGB subpixel rendering छोड़ दिया, और यह GPU तकनीक से जुड़ा फैसला था। लेकिन चूँकि मूल लेख ने दिखाया कि GPU पर भी यह संभव है, तो शायद कोई और वजह, कमी, या stack integration की कठिनाई रही होगी
• यह उल्लेख कि Cosmic Text (Cosmic DE) शायद Swash के ज़रिए GPU पर subpixel rendering सपोर्ट कर सकता है
• अगर आपको WebGL/WebGPU में SDF और MSDF implement करने में दिलचस्पी है, तो मेरे लिखे tutorial को देखें ट्यूटोरियल लिंक
• Rust में implemented WebGPU (WGPU) में दिलचस्पी होने का ज़िक्र। यह भी कहा कि यह tutorial काफ़ी advanced लगा, और JS examples को Rust में बदलकर सीखना असरदार रहा
• साइट का format बहुत पसंद आया और कहा कि मैं भी GPU से जुड़े tutorials इसी तरह बनाना चाहूँगा। यह भी पूछा गया कि क्या यह किसी खास template पर आधारित है या किसी course का हिस्सा है
• यह जानकारी साझा की गई कि Slug library एक commercial middleware है जो GPU glyph rasterizer implement करती है Slug Library
• यह राय कि Slug वेबसाइट पर algorithm काफ़ी विस्तार से बताए गए हैं, जो दिलचस्प है। साथ ही यह सवाल कि क्या इस पर patents हैं। cosmic-text का font parsing/layout इस्तेमाल करके open source wgpu version बनाना मज़ेदार हो सकता है, लेकिन बाद में Slug से lawsuit आ जाए तो मुश्किल होगी
• इस क्षेत्र से कम परिचित लोगों के लिए SDF text rendering का इतिहास और मौजूदा स्थिति का सारांश। Valve ने 2007 में SDF-आधारित architecture पेश किया था, और बाद में 2012 में Glyphy (बेहदाद एस्फहबोद) ने GPU-आधारित SDF implementation पेश की, लेकिन मुख्यधारा के OS और web browsers अब भी 1990s-शैली के Truetype तरीके पर टिके हैं। यह तरीका छोटा और हल्का है, लेकिन subpixel alignment या arbitrary layout को support नहीं करता, और text zoom या 3D transforms पर भी बड़ी सीमाएँ हैं। शायद इस तकनीकी प्रगति की रफ़्तार धीमी इसलिए है कि risk के मुकाबले लाभ बड़ा नहीं है, और rendering ही नहीं बल्कि line breaking जैसे जटिल layout processing में भी GPU/CPU cooperation मुश्किल है
• यह टिप्पणी कि line breaking जैसे text layout काम वास्तव में rendering से लगभग अलग हैं
• Servo का Pathfinder GPU compute shaders का उपयोग करके कहीं बेहतर performance वाला GPU text rendering पहले ही implement कर चुका है
• WebKit के GPU text rendering तरीके पर लेख लिंक. यह इशारा कि मौजूदा चरण में भी string से bitmap तक कुछ processing GPU पर संभव है, लेकिन जिस ‘subpixel anti-aliasing’ की अपेक्षा की जाती है, वह GPU प्रचार में अक्सर गायब रहती है
• यह भी बताया गया कि सिर्फ Windows ही नहीं, Chrome/Firefox में भी subpixel anti-aliasing तक की GPU acceleration कई साल पहले से मौजूद है। इसलिए यह मानना कि नई तकनीक इस्तेमाल नहीं हो रही, एक ग़लतफ़हमी है
• इतने संक्षिप्त और साफ़ overview के लिए धन्यवाद
• अगर subpixel rendering चाहिए, तो यह मानकर चलना होगा कि display की subpixel grid सही-सही पता हो। हर monitor के लिए अलग setting माँगना ही एकमात्र तर्कसंगत UX है। OS को screen rotation जैसी चीज़ें भी संभालनी होंगी
• लेखक की तरह मेरा भी मानना है कि सबसे आदर्श तरीका यह होगा कि display अपनी subpixel structure सीधे system को बताए
• नतीजे को शानदार बताया गया, साथ ही यह राय भी कि subpixel anti-aliasing का शुरुआती 2000s के LCD दौर में स्पष्ट फ़ायदा था, लेकिन high-resolution Retina displays के दौर में यह लगभग निरर्थक हो गया है। कमियों में opaque backgrounds पर ही लागू होना, post-processing (resize, mirroring, blur आदि) न कर पाना, और screenshots का दूसरे devices पर अजीब दिखना शामिल हैं
• यह डेटा भी दिया गया कि subpixel AA हटाने से चीज़ें सरल ज़रूर होंगी, लेकिन अब भी 96dpi, 1366x768 जैसे low-resolution displays वाले desktop users काफ़ी हैं (Firefox hardware survey डेटा)
• high-resolution screen उपयोगकर्ता होने के नाते low-resolution users को नज़रअंदाज़ करना गैरज़िम्मेदाराना है, यह राय भी जोड़ी गई
• यह चिंता भी जताई गई कि भले subpixel layout protocol आ जाए, कुछ manufacturers उसे ग़लत implement करेंगे, जिससे आम users के लिए समझना मुश्किल rendering problems पैदा होंगी
• cursive handwriting font को देखकर पहली प्रतिक्रिया यह थी: “आख़िर किसे लगा कि ऐसी cursive अच्छी idea है?”
• यह जवाब कि handwriting, खासकर dip pen या fountain pen के दौर में लिखने वाले लोगों को यह पसंद रही होगी
• यह भी समझाया गया कि जो लोग बहुत पत्र लिखते थे, वे cursive इस्तेमाल करते थे, और internet तथा लंबी दूरी की मुफ़्त कॉलिंग आने के बाद cursive का उपयोग घट गया
• यह सवाल कि code link मिल नहीं रहा