GPU पर साफ़ टेक्स्ट रेंडर करना

 (osor.io)
1 पॉइंट द्वारा GN⁺ 2025-06-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • मौजूदा Multi-Channel SDF तरीके में पतले स्ट्रोक, बड़े atlas, scale-down/scale-up और smooth movement में सीमाएँ बची हुई थीं, इसलिए इसे GPU runtime rasterization के रूप में फिर से implement किया गया
  • नई pipeline अभी दिख रहे glyphs का केवल Bézier curve data GPU को भेजती है, runtime पर उन्हें atlas में draw करती है और फिर screen पर sample करती है
  • अगर glyph screen पर बना रहता है, तो atlas cache बनाए रखते हुए samples accumulate करके quality बढ़ाई जाती है; पहले frame में 8 samples-per-pixel से शुरू कर अधिकतम 512 samples तक refine किया जाता है
  • cache key में font, glyph_index, pixel size और subpixel offset शामिल हैं; 8-bit fixed-point के ज़रिए पास की positions और sizes को एक ही value में fold करके reuse बढ़ाया जाता है
  • monitor-specific RGB subpixel structure को sample areas के रूप में model करने से OLED G9 जैसे non-standard arrangements में भी color fringing घटाई जा सकती है, और Radeon 9070 पर 4K full-screen text demo में लगभग 0.1ms peak cost दिखी

SDF के बजाय runtime vector rasterization चुनने की वजह

  • मौजूदा implementation Multi-Channel Signed Distance Fields का इस्तेमाल करता था और आम तौर पर अच्छा काम करता था, लेकिन real-world use में कुछ constraints बाकी थे
    • Quality: पतले strokes या बहुत detail वाले fonts में features गायब हो जाते थे या artifacts बनते थे, और कई बार higher-resolution SDF की जरूरत पड़ती थी
    • Atlas size: SDF offline generate होकर atlas में store होता है, इसलिए बहुत glyphs वाले Japanese/Chinese fonts को single atlas में bake करना मुश्किल होता है
    • Flexibility: scale-down/scale-up issues या subpixel anti-aliasing जैसे नए ideas लागू करना कठिन था, और runtime में generate/edit की जा सकने वाली vector images के लिए भी fit नहीं था
    • Simplicity: original glyph curves को intermediate texture में बदलने वाला step system complexity बढ़ाता है
  • Miama जैसे Latin font को भी हर glyph के लिए 64×64 area वाला 4096×1152 atlas चाहिए था, और runtime पर कई fonts इस्तेमाल करने पर memory और streaming bandwidth cost बढ़ जाती है
  • नए approach का goal glyph designer द्वारा बनाई गई Bézier curves को ज्यादा directly इस्तेमाल करके original data से final pixels तक के transformation steps घटाना है

पूरी pipeline

  • core idea यह है कि offline सभी glyphs को पहले से bake करने के बजाय, अभी visible glyphs की curves ही GPU को भेजकर जरूरत के समय rasterize किया जाए
  • processing flow सरल है
    • font से glyph curve data load करना
    • GPU runtime पर glyph को atlas में rasterize करता है
    • screen output के समय उस atlas को sample करना
  • अगर वही glyph बाद के frames में भी इस्तेमाल होता रहता है, तो उसे atlas में रखा जाता है और samples accumulate करके high-quality subpixel anti-aliasing तक refine किया जाता है
  • vector representation को directly render करने से resolution changes handle करना आसान होता है, और सिर्फ पूरे pixel coverage ही नहीं बल्कि हर subpixel element का coverage भी calculate किया जा सकता है

glyph curves की processing

  • font loading के लिए FreeType को offline tool की middle layer के तौर पर इस्तेमाल किया गया, ताकि supported formats पढ़े जा सकें और हर glyph की curves traverse करके custom asset format में store की जा सकें
  • glyph curves में lines, quadratic Bézier, cubic Bézier शामिल हो सकते हैं; shader को simple रखने के लिए सबको quadratic Bézier में convert किया गया
    • line को दो points के बीच में एक control point जोड़कर quadratic Bézier बनाया जाता है
    • cubic Bézier को दो quadratic Bézier में divide किया जाता है, जो degree reduction वाला lossy conversion है
  • cubic Bézier को दो quadratic Bézier में divide करने का तरीका आजमाए गए ज्यादातर fonts में अच्छा काम करता है, लेकिन error और घटाने के लिए ज्यादा sophisticated methods भी संभव हैं
  • अगर higher-quality conversion चाहिए, तो offline tool से TrueType .ttf जैसे सिर्फ quadratic Bézier वाले format में बदलकर इस conversion को ही avoid किया जा सकता है
  • Desmos graph में input cubic Bézier और result वाले दो quadratic Bézier के shapes compare किए जा सकते हैं

coverage calculation और curve access optimization

  • coverage pixel level पर horizontal ray को left से right shoot करके, curves के साथ intersections check करके winding number accumulate करने के तरीके से calculate की जाती है
  • mathematical background और implementation के लिए GreenLightning का GPU Font Rendering और Sebastian Lague का Rendering Text video देखे जा सकते हैं
  • intersection calculation की inaccuracies किसी खास height के sample पर हो सकती हैं, लेकिन सैकड़ों samples accumulate करने पर एक-दो errors average के बाद लगभग दिखाई नहीं देते
    • अधिकतम 512 samples accumulate करते समय अगर एक sample गलत हो, तो 0 की जगह 1/512=0.00195, या 1 की जगह 511/512=0.99804 हो जाता है
    • coverage extreme values के पास होने पर clamp करने के लिए threshold भी रखा जा सकता है
  • sample positions के distribution के लिए Martin Roberts का $R_2$ sequence इस्तेमाल किया गया, और Shadertoy example में time के साथ distribution देखा जा सकता है
  • curve access cost घटाने के लिए glyph को कई horizontal bands में बांटा गया, और हर band को छूने वाली curves ही bitset में store की गईं
    • सिर्फ horizontal rays trace करने से हर texel को check करनी पड़ने वाली curves का set काफी घट जाता है
    • wave level पर same band range access करवाने से curve iteration और reads को scalarize किया जा सकता है
    • compute shader में atlas पर rasterize करते समय threads को row-major में horizontally pack किया जाता है, ताकि wave द्वारा छुई जाने वाली band range कम से कम हो

atlas packing और cache key

  • शुरुआत में सीधे screen पर rasterize किया गया था, लेकिन हर frame high-quality anti-aliasing calculate करने की cost ज्यादा थी
  • अधिकतर text कई frames तक same size और position पर रहता है, और same glyph same size में repeat होता है, इसलिए atlas और temporal accumulation उपयुक्त हैं
  • अगर जरूरी glyph atlas में नहीं है, तो atlas space allocate करके rasterization शुरू करता है, और अगर पहले से है तो existing result को वैसे ही इस्तेमाल करता है
    • frame के दौरान atlas में glyphs को check करके तय किया जाता है कि उन्हें keep करना है, और sample करना है, या unused होने पर space free करना है
  • atlas key में ये elements शामिल हैं
    • font
    • glyph_index
    • quantized_size_in_pixels_x, quantized_size_in_pixels_y
    • quantized_subpixel_offset_x, quantized_subpixel_offset_y
  • subpixel offset frac(pixel_position) के बराबर है, और जब glyph pixel grid से exact align न हो या smoothly scroll हो, तो position के अनुरूप anti-aliasing result बनाने के लिए यह जरूरी है
  • floating-point values को सीधे key के रूप में इस्तेमाल करने पर mathematically same values भी bit level पर अलग हो सकती हैं, इसलिए 8-bit fractional fixed-point से nearby positions और sizes को same value में fold किया जाता है
  • किसी text editor में बहुत static text हो और monospaced font इस्तेमाल हो, तो character spacing और line positions को pixel boundaries से align करके same glyph के atlas cache hit rate को बढ़ाया जा सकता है

Z-Order आधारित atlas placement

  • runtime glyph placement में Z-Order Packing और free-cell bitset का इस्तेमाल होता है
  • Morton code आधारित Z-Order 2D cells को लंबी 1D array की तरह handle करने देता है, और power-of-two count जितने contiguous cells allocate करने पर 2D atlas में square region मिलता है
  • base cell 16×16 texel है, और glyph size को next power of two तक round up किया जाता है
    • उदाहरण के लिए 25×29 glyph को 32×32 chunk allocate किया जाता है
    • इस मामले में 16×16 cells की 4 units चाहिए, इसलिए aligned contiguous 4 bits खोजकर इस्तेमाल किए जाते हैं
  • Latin alphabet के लंबे और पतले glyphs अक्सर vertical होते हैं, इसलिए transposed Z-Order इस्तेमाल करने पर l, j, i, 1 जैसे glyphs आधी जगह में आ सकते हैं
  • इसके विपरीत, Arabic जैसी scripts में अगर लंबे और पतले glyphs horizontal हों, तो standard Z-Order ज्यादा suitable है

temporal accumulation से quality बढ़ाने का तरीका

  • अगर glyph atlas में बना रहता है, तो हर frame थोड़ा-थोड़ा sample जोड़कर result refine किया जा सकता है
  • default schedule में glyph पहली बार दिखने वाले frame पर 8 samples-per-pixel, अगले frame पर 4, फिर 2, और उसके बाद हर frame 1 sample जोड़कर total 512 तक accumulate किया जाता है
  • first-frame quality ऊंची रखने की वजह यह है कि smoothly move करने या size बदलने वाला glyph हर frame नए सिरे से initialize होने जैसा होता है
  • quality और performance को कई तरीकों से adjust किया जा सकता है
    • हर frame add किए जाने वाले samples/rays की संख्या
    • glyph के शुरुआती कुछ frames में sample increase करना है या नहीं
    • per-frame total samples की upper limit
    • existing glyphs को हर frame के बजाय कुछ frames पर update करने वाली time-slicing
    • glyph curves की संख्या के हिसाब से intersection-check cost limit करने का तरीका
  • इस implementation में performance बड़ी समस्या नहीं रही; intro वाला full-screen text Radeon 9070 पर 4K में करीब 0.1ms peak दिखाता है, और glyphs maximum sample count तक पहुंचने पर cost तेजी से 0 के करीब हो जाती है

subpixel anti-aliasing और color fringing

  • subpixel anti-aliasing monitor pixel के अंदर red, green, blue elements को अलग-अलग sample areas मानकर render करता है
  • traditional RGB LCD की vertical-stripe structure में horizontal resolution effectively 3 गुना हो जाती है, जिससे 4K में 3840×2160 को 3840×6480 जैसा treat किया जा सकता है
  • OLED G9 जैसे monitors में standard RGB vertical stripes से अलग non-standard subpixel structure होना समस्या है
    • default RGB vertical rectangle structure assume करने पर ऊपर green और नीचे magenta color fringing दिखती है
    • monitor की वास्तविक subpixel structure के अनुसार sample positions set करने पर color fringing लगभग नहीं होती और smooth result मिलता है
  • Subpixel Zoo अलग-अलग subpixel structures के examples दिखाता है, और LG WOLED का red-white-blue-green structure standard order से अलग example है
  • subpixel elements को उनकी actual physical size से बड़ा मानकर और उन्हें आपस में overlap कराकर set करने से ज्यादा accurate result मिला
    • subpixel की light naturally mix होती है और थोड़ी फैलती है, इसलिए sample area physical subpixel से बड़ा होने जैसा behave करता है
    • sample area को pixel के बाहर भी फैलना चाहिए, और neighboring pixels की subpixel light के साथ भी mix होना चाहिए
  • Evan Wallace का Easy Scalable Text Rendering subpixel anti-aliasing के बाद horizontal blur की जरूरत मानता है; यह subpixel elements को बड़ा और overlapping मानने के तरीके जैसा ही effect देता है

display subpixel जानकारी software को मिलनी चाहिए

  • अगर monitor की arbitrary subpixel structure तक access मिल सके, तो general subpixel anti-aliasing और text rendering quality सुधारी जा सकती है
  • common display protocol के जरिए ऐसी information मिल जाए, तो standard-array monitors पर भी hardware-specific finer rendering संभव होगा
  • display manufacturers को text rendering problems की वजह से बेहतर subpixel structures के experiments से बचना नहीं पड़ेगा
  • Samsung ने QD-OLED में G8 से G9 पर जाते समय इस issue को कम करने के लिए subpixel structure बदला, और LG WOLED व Samsung QD-OLED में color fringing अक्सर point out किया जाता है
  • इस issue को hardware replacement की तुलना में software correction से handle करने की गुंजाइश है

real-time glyph rendering की practical value

  • अच्छी UI और text quality product की perceived quality को बढ़ा सकती है
  • games में text boxes, menus, titles, notifications जैसे elements अक्सर user's attention खींचते हैं, और खराब text quality experience को उतना ही प्रभावित कर सकती है जितना खराब rendered 3D scene
  • Persona series, Metaphor: ReFantazio, Nier: Automata UI और text presentation के अच्छे examples हैं
  • real-time glyph rendering quality सुधारने की कोशिश UI और game rendering, दोनों में practical value रखती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-06-14
Hacker News की राय

  • पहले वीडियो में तिरछे j के बिंदु का क्या हुआ?

  • Subpixel font rendering पठनीयता के लिए महत्वपूर्ण है, लेकिन जैसा कि लेख में बताया गया है, मौजूदा डिस्प्ले standards से pixel layout specification नहीं मिल पाना अफसोस की बात है

    • यह सिर्फ standard resolution displays पर लागू होता है, और तब भी यह “ज़रूरी” से ज़्यादा बस अच्छा-हो-तो-अच्छा है
      दुनिया धीरे-धीरे Retina-स्तर के displays की ओर बढ़ गई है, और वहाँ subpixel rendering की ज़रूरत लगभग नहीं रह जाती
      screenshots किसी खास subpixel layout से बंध जाते हैं, और bitmap को scale up/down करना भी मुश्किल हो जाता है
      यह CRT और Retina के बीच LCD युग का एक अस्थायी नवाचार था, और अब यह पीछे देखने वाली technology के क़रीब है। Apple ने कुछ साल पहले इसे macOS से हटाया, उसके पीछे वजह थी
    • DisplayID standard, यानी EDID का आधुनिक successor, https://en.wikipedia.org/wiki/DisplayID#0x0C_Display_device_... के अनुसार कम-से-कम इसे अनुमति देने का इरादा रखता दिखता है
      सोचता हूँ कि क्या display manufacturers इसे implement नहीं करते। किसी भी हालत में, सबसे आम display models के लिए यह ऐसी जानकारी है जिसे hardware information database में आसानी से infer करके रखा जा सकता है
    • समझ नहीं आता कि यह अब तक क्यों नहीं हो पाया। लगता है यह काम तो दशकों पहले से संभव था
      लेख शानदार है, और अलग-अलग उदाहरण दिखाने वाला “subpixel zoo” भी लिंक करता है: https://geometrian.com/resources/subpixelzoo/
    • “त्रासदी” कहना थोड़ा बढ़ा-चढ़ाकर कहना है। हर operating system को पुराने Windows के ClearType tuner जैसी सुविधा देनी चाहिए और परिणाम को screen या monitor model के हिसाब से याद रखना चाहिए
      उन अपरिहार्य मामलों में भी यह तरीका चाहिए होगा जहाँ monitor गलत layout report करता है
    • Subpixel rendering ज़्यादातर भाषाओं में ज़रूरी नहीं है
      बिना anti-aliasing वाले bitmap fonts या hinted vector fonts से भी पठनीयता बहुत अच्छी मिलती है
      यह सिर्फ उन भाषाओं में महत्वपूर्ण हो जाता है जहाँ अक्षरों में बहुत जटिल बारीकियाँ होती हैं, जैसे Chinese या Japanese

  • GTK4 ने rendering को GPU पर ले जाते समय RGB subpixel rendering छोड़ दिया
    सुना था कि GPU-केंद्रित फैसले की वजह से RGB subpixel rendering जारी रखना मुश्किल हो गया, लेकिन लेख दिखाता है कि यह संभव है
    अगर ऐसा है, तो GTK की वजह कुछ और रही होगी, या फिर बताए गए समाधान में कुछ कमियाँ होंगी, या वह मौजूदा stack में अच्छी तरह integrate नहीं होता होगा

    • Cosmic Text(Cosmic DE) swash के ज़रिए GPU पर यह कर सकता है। यह subpixel rendering को support करता है

  • अगर आपको WebGL / WebGPU में SDF और MSDF implement करने के तरीकों में दिलचस्पी है, तो मेरे द्वारा लिखी यह tutorial देख सकते हैं: https://infinitecanvas.cc/guide/lesson-015#msdf

    • अच्छा लग रहा है। मुझे Rust के WebGPU implementation WGPU में दिलचस्पी है, और यह tutorial खुद को इस तरह promote नहीं करती, लेकिन असल में advanced course जैसी लगती है
      मैंने JavaScript examples को Rust में port करके देखा है; सीधा copy/paste तो नहीं किया जा सकता, लेकिन APIs काफ़ी मिलती-जुलती हैं, इसलिए port करना आसान है और सीखने के लिए आदर्श है
      इससे WGPU docs को सहजता से इस्तेमाल करने की आदत भी पड़ती है
    • साइट का format सच में बहुत अच्छा है
      मुझे GPU-संबंधित tutorials बनाना पसंद है, इसलिए मैं भी कुछ ऐसा ही बनाना चाहूँगा; सोच रहा हूँ कि क्या यह कोई मौजूदा template है या किसी course का हिस्सा

  • Slug library ऐसा GPU glyph rasterizer implement करने वाला commercial middleware है
    [1]: https://sluglibrary.com/

    • वेबसाइट पर वे algorithm का काफ़ी हिस्सा सीधे समझाते हैं; सोच रहा हूँ कि क्या इस पर patents हैं
      cosmic-text के font parsing और layout के कुछ हिस्से लेकर open source wgpu version बनाना मज़ेदार होगा, लेकिन अगर आखिर में Slug मुक़दमा कर दे तो वह बिलकुल भी मज़ेदार नहीं होगा

  • GPU को देखकर लगता है जैसे उसमें लगभग अनंत vertex/pixel drawing क्षमता हो, फिर भी अब तक समझ नहीं आता कि text को offline render करके atlas में क्यों रखा जाए और SDF जैसी तरकीबें क्यों इस्तेमाल की जाएँ
    लेख में भी कहा गया है कि glyph curves को atlas में लिखा जाता है; सोचता हूँ shader सीधे text render क्यों नहीं कर सकता
    Bezier को triangle mesh में बदलने का कोई तरीका तो ज़रूर होगा। मैं CAD apps के लिए GPU text renderer पर अभी-अभी काम शुरू करने वाला हूँ, तो उम्मीद है जल्द वजह समझ आ जाएगी

    • जब एक ही glyph को बार-बार render करना हो, तो नतीजे को cache करना ज़्यादातर मामलों में सस्ता पड़ता है
      GPU तेज़ है, लेकिन अनंत तेज़ नहीं, और पहले से render की गई texture को sample करने में बहुत अच्छा है
      यह सिर्फ speed का मामला नहीं, power consumption का भी मामला है। अगर आप पहले ही monitor refresh rate तक पहुँच चुके हैं, तो अतिरिक्त performance responsiveness नहीं बढ़ाएगी, लेकिन battery life बढ़ा सकती है
      rendering में “काफ़ी तेज़” जैसी कोई चीज़ नहीं होती; और तेज़ होना हमेशा फ़ायदेमंद है
    • बुनियादी fonts में भी सामान्य display sizes पर triangle density बहुत ज़्यादा होती है
      आधुनिक GPU architectures high-density geometry को अच्छी तरह handle नहीं कर पाते। ऐसे मामलों में triangles को सीधे GPU पर भेजना atlas या दूसरी तकनीकों की तुलना में बहुत अक्षम होता है
      ज़्यादातर GPUs pixel shader को 4 के समूहों में dispatch करते हैं। अगर सारे triangles 1 pixel आकार के हों, तो shader threads में से 3 visual output में कोई योगदान नहीं देंगे
      इसे quad overdraw कहा जाता है। ऊपर से vertex processing में भी बिना किसी असली वजह के काफ़ी समय लगता है
    • GPU के पास अनंत vertex/pixel drawing क्षमता नहीं होती। text को सीधे render करना बस ज़्यादा महँगा पड़ता है
      यह किया जा सकता है, लेकिन बिना खास लाभ के आप frame budget का एक हिस्सा छोड़ देंगे और power usage बढ़ा देंगे
    • triangles गलत विकल्प हैं, लेकिन सवाल की बड़ी दिशा सही है
      लेखक atlas का इस्तेमाल करता है क्योंकि वह Bezier curves को प्रति pixel अधिकतम 512 samples तक supersample करता है, जो बहुत महँगा है
      इसकी जगह अगर Bezier curve region और subpixel region के intersection integral की गणना की जाए, तो यह कहीं तेज़ हो सकता है, atlas के बिना real time में चल सकता है, और supersampling से भी अधिक सटीक हो सकता है
    • GPU बहुत तेज़ है, लेकिन अनंत नहीं। अगर आप GPU time text पर खर्च करते हैं, तो उसे कहीं और खर्च नहीं कर सकते
      और लगभग हमेशा आप वह समय किसी और चीज़ पर खर्च करना चाहेंगे
      जितना अधिक GPU time चाहिए होगा, उतना ही तेज़ minimum required hardware भी चाहिए होगा। text शानदार और महत्वपूर्ण है, लेकिन शायद इतना महत्वपूर्ण नहीं कि उसके लिए users या customers खो दिए जाएँ

  • “नए OLED दिखने में अच्छे हैं, लेकिन non-standard subpixel structure की वजह से color fringing की समस्या होती है” — बात शायद इससे भी बदतर लगती है
    मेरी समझ के अनुसार, मामला सिर्फ non-standard होने का नहीं है, बल्कि OLED में कई subpixel layouts होते हैं जो एक-दूसरे के साथ compatible नहीं हैं
    इसी वजह से FreeType ने OLED के लिए subpixel rendering लागू नहीं की, और अगर आपको text work करना है तो OLED से बचने की यह एक वजह है
    यह सिर्फ FreeType की समस्या भी नहीं है; Qt, GTK जैसे GUI toolkits को भी साथ में align होना पड़ता है। इस पर कोई प्रगति हुई है या नहीं, मुझे पता नहीं
    अच्छा होता अगर monitor के subpixel structure को programmatically access किया जा सकता, और शायद ऐसी जानकारी EDID के जरिए दी जानी चाहिए

    • कुछ OLED में subpixel layout काफ़ी हद तक standard भी होता है
      उदाहरण के लिए, मेरे laptop में vertical BGR layout है, और FreeType व KDE इसे अच्छी तरह support करते हैं
      अजीब layouts अक्सर HDR displays में इसलिए आते हैं क्योंकि कुछ colors, खासकर blue, बहुत जल्दी burn out न हों, इसके लिए हर color के लिए अलग size इस्तेमाल करना पड़ता है
    • सिद्धांत रूप में यह सही है, लेकिन व्यवहार में मैं 4K OLED display पर code लिख रहा हूँ और मुझे कोई artifact महसूस नहीं हुआ

  • यह बेहद प्रभावशाली काम है
    जो लोग इस क्षेत्र से परिचित नहीं हैं, उनके लिए जोड़ दूँ कि Valve ने games के लिए SDF text rendering बनाया था और 2007 में इस विषय पर एक pathbreaking paper प्रकाशित किया था
    आज भी यह video games में लगभग बिना बदलाव के बहुत व्यापक रूप से इस्तेमाल होने वाली तकनीक है
    2012 में Behdad Esfahbod ने OpenGL ES पर GPU में चलने वाला SDF implementation, Glyphy, बनाया था, और performance व fast text transforms जैसी नई क्षमताओं के कारण उसे काफ़ी मान्यता मिली, लेकिन उसका व्यापक उपयोग नहीं हुआ
    आधुनिक operating systems और web browsers ऐसी तकनीकों की बजाय 1990s-style TrueType rasterization पर निर्भर रहना पसंद करते हैं
    यह हल्का और प्रभावी तरीका है, लेकिन जैसा लेख में दिखता है, इसमें subpixel alignment या arbitrary subpixel layouts नहीं किए जा सकते, zoom in/out में performance cost ज़्यादा है, और skew, rotation, 3D transform जैसी जटिल transformations भी text rendering engine के अंदर नहीं की जा सकतीं
    अगर rotated या transformed text चाहिए, तो bitmap को resample करना पड़ता है, जिससे readability देने वाली सारी छोटी विशेषताएँ बिगड़ जाती हैं और नतीजा अच्छा नहीं दिखता
    प्रगति धीमी होने की वजह शायद यह हो सकती है कि लाभ की तुलना में काम और risk बहुत ज़्यादा है। अगर आप सोचें कि किसी आधुनिक web browser engine को GPU-accelerated text rendering के लिए फिर से लिखा जाए, तो यह आसान नहीं है
    glyph rendering तो सिर्फ एक हिस्सा है, line breaking एक अलग समस्या है। CPU और GPU के बीच बहुत communication चाहिए हो सकती है, जिससे यह धीमा पड़ सकता है, और software व GPU का गहरा integration भी कठिन है

    • text shaping, layout और line breaking तक का हिस्सा rendering से लगभग पूरी तरह अलग है, इसलिए ऐसा क्यों कहा जा रहा है, यह समझ नहीं आया
    • https://github.com/servo/pathfinder यह काम GPU compute shaders से करता है
      यह तरीका SDF की तरह hardware 3D rendering pipeline में जबरन फिट करने की तुलना में performance में काफ़ी बेहतर है
    • रिकॉर्ड के लिए कहूँ तो, subpixel anti-aliasing सहित text rendering Windows में बहुत पहले से GPU-accelerated रहा है, और Chrome/Firefox में भी काफ़ी समय से GPU acceleration है
      Safari में भी शायद ऐसा ही है, लेकिन मैंने खुद जाँच नहीं की, इसलिए पक्के तौर पर नहीं कह सकता
      यह सोचना कि state of the art या users तक पहुँचने वाले implementations में प्रगति नहीं हुई है, गलत है
    • SDF कोई सर्व-उपयोगी समाधान नहीं है
      SDF किसी दिए गए pixel पर glyph edge तक की local distance को data के 2D array यानी field में encode करता है, और यह distance glyph के अंदर है या बाहर, इसे sign bit से दिखाता है
      हर glyph के पास एक छोटा data map होता है, जिसे GPU-friendly image file format में साथ pack किया जाता है, और इसके साथ एक description file होती है जो बताती है कि हर glyph की partial image कहाँ मिलेगी; इन्हीं के साथ SDF rendering shader इस्तेमाल होता है
      इस तरह की glyph definitions field values के बीच linear interpolation के प्रति बहुत robust होती हैं, इसलिए अपेक्षाकृत low-resolution maps से भी लगभग perfect scaling मिल सकती है। GPU भी map के pixel values interpolate करने में माहिर होता है
      लेकिन महत्वपूर्ण बात यह है कि development के दौरान इन maps को उन सभी characters के लिए पहले से process करना पड़ता है जिन्हें मौजूदा font system से render करना है। font द्वारा supported हर character के लिए यह चाहिए
      सभी characters को high-resolution bitmap font के रूप में render करने की तुलना में data बहुत कम होता है, लेकिन font outline definitions की तुलना में फिर भी बहुत अधिक होता है
      operating system या browser जैसे systems, जिन्हें दुनिया भर के हर संभावित text को support करना होता है, वे SDF को text rendering system के रूप में इस्तेमाल नहीं कर सकते। पूरे Unicode character set के लिए SDF maps चाहिए होंगे, जो बहुत बड़े हो जाएँगे
      games के लिए यह इसलिए ठीक बैठता है क्योंकि वहाँ अक्सर localization पूरी तरह flawless होना ज़रूरी नहीं होता, या पूरी तरह arbitrary text दिखाने की ज़रूरत नहीं होती
      मूल रूप से SDF emoji को भी support नहीं कर सकता। कारण यह है कि यह केवल glyph edge तक की दूरी encode करता है, glyph के अंदर की color information नहीं
      हालाँकि, कई colors support करने वाला एक improved variant, Multichannel SDF, मौजूद है, लेकिन कुल colors की संख्या पर सीमाएँ हैं
      वास्तव में, अगर आप किसी ऐसे game को ध्यान से देखें जो in-game text के लिए SDF इस्तेमाल करता है और जिसमें दुनिया भर की community के interact करने वाला chat system भी है, तो संभव है कि in-game text और chat system का text rendering अलग हो
    • आधुनिक web browser engines को GPU-accelerated text rendering के लिए फिर से लिखना कठिन है, लेकिन मुझे लगा था कि यह काम आंशिक रूप से पहले से हो रहा है
      https://keithclark.co.uk/articles/gpu-text-rendering-in-webk... (2014) के अनुसार, “Chrome, Safari या Opera के मौजूदा versions में जब किसी element को GPU पर promote किया जाता है, तो वह subpixel anti-aliasing खो देता है और text grayscale तरीके से render होता है”
      अगर ऐसा है, तो मैं जानना चाहता हूँ कि आखिर क्या चीज़ अभी भी missing है। उस वाक्य के मुताबिक, कम-से-कम UTF-8 string से bitmap तक जाने वाली pipeline का कुछ हिस्सा तो GPU पर किया जा सकता है, ऐसा लगता है

  • काफ़ी प्रभावशाली काम है
    लेकिन निजी तौर पर मुझे लगता है कि subpixel anti-aliasing का खास मतलब नहीं है। 2000 के दशक में, जब लोग 72dpi मॉनिटर इस्तेमाल करते थे, यह एक ठीक-ठाक hack था, लेकिन आधुनिक Retina स्क्रीन पर इसे पहचानना मुश्किल है और बहुत छोटे से सुधार के बदले कई नुकसान मिलते हैं
    यह केवल opaque background पर काम करता है, और rasterized नतीजे पर resizing, mirroring, blur जैसे effects लागू नहीं किए जा सकते, साथ ही अगर screenshot को किसी दूसरे display पर देखा जाए तो वह और खराब दिखता है

    • subpixel anti-aliasing हटाने से चीज़ें काफ़ी सरल हो जाएँगी, लेकिन अभी भी बहुत से desktop users low DPI monitors इस्तेमाल करते हैं
      Firefox hardware survey [1] के अनुसार 16% users 1366x768 resolution display इस्तेमाल करते हैं
      यह सिर्फ़ पुराने hardware की समस्या नहीं है; 96dpi monitors और laptops आज भी बनाए जा रहे हैं
      [1]: https://data.firefox.com/dashboard/hardware
    • आख़िर में यह बात कुछ ऐसी लगती है: “मैं high DPI screen इस्तेमाल करता हूँ, इसलिए जो लोग ऐसा नहीं करते उनकी मुझे परवाह नहीं”
      बाकी तर्क उन जगहों पर subpixel rendering से मिलने वाले बेहतर परिणामों की तुलना में ज़्यादा महत्वपूर्ण नहीं लगते जहाँ यह लागू हो सकती है
    • मान लें कि लेखक की इच्छा के मुताबिक display की subpixel arrangement पता करने वाला कोई protocol बन भी जाए और व्यापक रूप से अपनाया भी जाए, तब भी संभावना है कि कुछ manufacturers इसे ग़लत implement करें और ऐसे rendering problems पैदा हों जिन्हें end users के लिए समझना बहुत मुश्किल हो

  • यह समझना ज़रूरी है कि SDF सबसे नज़दीकी edge तक pixel की दूरी निकालता है, जबकि पारंपरिक font renderer pixel coverage की गणना करता है
    pixel coverage ही बेहतर है। छोटे fonts में, जहाँ edges आपस में मिलते हैं, SDF खराब दिख सकता है
    high PPI displays पर शायद यह कम समस्या हो। मैंने खुद एक SDF renderer implement किया था, और वह FreeType से बदतर दिखा

    • coverage और distance का फर्क असली मुद्दा नहीं है। distance field renderer में भी coverage बहुत आसानी से निकाला जा सकता है
      लेकिन यह बात सही है कि intersections, या सामान्य रूप से sharp corners पर distance field समस्याएँ पैदा करता है
      कई distance fields रखकर और उनके intersections को render करके इसे कुछ हद तक कम किया जा सकता है। उदाहरण के लिए https://github.com/Chlumsky/msdfgen है