GTK के लिए नए रेंडरर

 (blog.gtk.org)
1 पॉइंट द्वारा GN⁺ 2024-01-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GTK का rendering आधार GL के लिए ngl और Vulkan के लिए vulkan के रूप में पुनर्गठित किया गया है, और दोनों renderer एक ही source से build होने वाली unified संरचना रखते हैं
  • common implementation Vulkan API flow पर आधारित है और GL 3.3+ व GLES 3.0+ के अंतर को abstract करता है, जिससे scene graph traversal और cache जैसी rendering infrastructure साझा रूप से इस्तेमाल होती है
  • नया renderer फिलहाल speed से ज्यादा correctness और maintainability को प्राथमिकता देता है, और antialiasing, fractional scaling, unlimited gradient color stops व dmabuf support को बेहतर करता है
  • app developers को glshader node unsupported होना, fractional position handling में बदलाव, और driver issues की संभावना जांचनी चाहिए; समस्या driver जैसी दिखे तब भी GTK को report करना बेहतर है
  • GTK 4.13.6 snapshot में ngl नया default है, लेकिन यह अभी trial rollout चरण में है; बड़े issue होने पर GTK 4.14 में पुराने gl renderer पर वापस लौटा जा सकता है

GL और Vulkan के लिए unified renderer

  • GTK ने GL के लिए नया renderer ngl और Vulkan के लिए नया renderer vulkan जोड़ा है
  • दोनों renderer एक ही source से build होते हैं, इसलिए इन्हें unified renderer कहा जाता है
  • implementation model Vulkan API का अनुसरण करता है, और GL 3.3+ व GLES 3.0+ के अंतर संभालने के लिए abstraction शामिल करता है
  • इस संरचना की वजह से renderer-specific तौर पर अलग-अलग maintain किए जाने वाले आधारभूत काम साझा किए जा सकते हैं
    • scene graph traversal
    • transform और अन्य state को maintain करना
    • texture और glyph cache
    • दोनों renderers को up-to-date बनाए रखने का काम

Metal और DirectX तक विस्तार करते समय शर्तें

  • इसी approach को macOS के Metal-based renderer या Windows के DirectX-based renderer तक बढ़ाने की संभावना है
  • Vulkan और GL के पक्ष में यह बात है कि वे मूल रूप से एक ही shader language, GLSL, साझा करते हैं
  • Metal या DirectX पर यही शर्त लागू नहीं होती, इसलिए shader को duplicate लिखना होगा या SPIRV-Cross जैसे conversion tool की जरूरत होगी
  • ऐसे काम में रुचि रखने वाले contributors का स्वागत है

implementation तरीका और ubershader

  • मौजूदा GL renderer हर rendernode type के लिए simple shader इस्तेमाल करता है, और complex content में अक्सर offscreen rendering पर निर्भर रहता है
  • unified renderer के पास भी ज्यादा शक्तिशाली per-node shader हैं, लेकिन यह offscreen के बजाय buffer data को interpret करने वाले complex shader भी साथ में इस्तेमाल करता है
  • game programming में इस approach को ubershader कहा जाता है
  • नया implementation मौजूदा GL renderer की तुलना में कम optimized है, लेकिन correctness और maintainability को प्राथमिकता देकर अधिक विविध rendernode trees को सही ढंग से handle कर सकता है

rendering quality और नई सुविधाएं

  • antialiasing

    • मौजूदा GL renderer pixel की एक line की boundaries के बीच आने जितने छोटे details खो सकता है
    • यह समस्या mnemonic जैसे underline को भी प्रभावित कर सकती है
    • unified renderer छोटे details को बेहतर preserve करता है, और primitive outlines में stair-step artifacts भी घटाता है

  • fractional scaling

    • antialiasing fractional scale को सही ढंग से handle करने का आधार बनता है
    • 1200×800 window को 125% पर scale करते समय unified renderer 1500×1000 framebuffer इस्तेमाल करता है
    • compositor से 2400×1600 image को downscale करवाने की तुलना में इसमें process करने वाले pixels काफी कम होते हैं और image ज्यादा sharp होती है

  • arbitrary gradients

    • मौजूदा GL renderer linear, radial और conic gradients में अधिकतम 6 color stops ही handle करता है
    • unified renderer color stops की संख्या unlimited रखने देता है
    • gradients पर भी antialiasing लागू कर sharp boundaries पर smooth lines बनाता है

  • dmabuf

    • GTK ने पिछली autumn में dmabuf support और graphics offloading पर काम किया
    • नया renderer इसे support करता है, और render_texture API के जरिए texture creation request मिलने पर dmabuf बनाने के लिए इसे extend करता है
    • फिलहाल यह extension केवल Vulkan renderer पर लागू है

app developers को किन बातों की जांच करनी चाहिए

  • glshader node unsupported

    • glshader node GTK 4.0 demo के लिए उपयोगी था, लेकिन मौजूदा GL renderer से मजबूती से जुड़ा हुआ है
    • यह node मौजूदा renderer द्वारा expose किए गए GLSL API को मानकर चलता है
    • नया renderer glshader node support नहीं करता
    • GTK docs सलाह देते हैं कि shader पर निर्भर होने से पहले validate करें, और fail होने पर ज्यादा simple shader या shader-less fallback path इस्तेमाल करें
    • GTK 4.0 के बाद mask node और straight-alpha texture support जैसी सुविधाएं जोड़ी गईं, इसलिए glshader node के कई use cases अब जरूरी नहीं रहे

  • fractional positions

    • मौजूदा GL renderer positions को round कर देता था, इसलिए fractional positions pass करने पर भी समस्या सामने नहीं आती थी
    • नया renderer specified position पर ही place करता है
    • यह अंतर unintended results बना सकता है, इसलिए जांचना चाहिए कि position वांछित value है या नहीं
    • खासकर cairo-style drawing से सावधान रहें, जिसमें एक line के pixels को ठीक से fill करने के लिए line को half-pixel position पर रखा जाता है

  • driver issues

    • नया renderer graphics driver को नए और अलग तरीके से इस्तेमाल करता है, इसलिए driver-side issues trigger होने की संभावना है
    • भले ही समस्या driver issue जैसी दिखे, GTK को report करना बेहतर है
    • इससे अलग-अलग drivers और hardware पर नया code कितना अच्छी तरह काम करता है, यह समझने में मदद मिलती है

मौजूदा performance स्थिति

  • नया renderer अभी मौजूदा renderer से faster नहीं है
  • मौजूदा GL renderer speed के लिए काफी optimized है, ज्यादा simple shader इस्तेमाल करता है और antialiasing जैसी सुविधाओं के लिए जरूरी calculations नहीं करता
  • लक्ष्य अंततः नए renderer को faster बनाना है, लेकिन फिलहाल नई सुविधाएं और correctness ज्यादा बड़ा सुधार हैं
  • सभी GPU-based renderers फिलहाल GTK apps को 60fps या 144fps पर render करने के लिए पर्याप्त तेज हैं
  • non-scientific benchmark में Vulkan renderer मौजूदा GL renderer के समान या कुछ cases में उससे आगे होने के करीब है
  • नया GL renderer धीमा क्यों है, इसकी वजह अभी trace नहीं की गई है

default बदलाव और exceptions

  • अभी release हुए GTK 4.13.6 snapshot में ngl renderer नया default बन गया है
  • यह बदलाव trial rollout है, और production readiness की पुष्टि करने के लिए कई apps में व्यापक testing से गुजरना होगा
  • बड़े issues दिखाई देने पर GTK 4.14 में मौजूदा gl renderer पर वापस लौटा जा सकता है
  • Vulkan renderer अभी default नहीं है
    • WebKit GTK4 port GL में काम करता है, लेकिन Vulkan में नहीं
    • GtkGLArea और GtkMediaStream फिलहाल GL textures बनाते हैं, और Vulkan renderer उन्हें सीधे import नहीं कर सकता
    • अगर ये समस्याएं निकट भविष्य में हल हो जाती हैं, तो default renderer decision पर फिर से विचार किया जाएगा
  • बहुत पुराने hardware पर GTK इस्तेमाल कर रहे हों तो मौजूदा GL renderer बेहतर हो सकता है
    • मौजूदा GL renderer GPU से कम requirements रखता है
    • GSK_RENDERER environment variable से renderer selection override किया जा सकता है
    • उदाहरण: GSK_RENDERER=gl

आगे संभावित काम

  • नया renderer उन features को implement करने का आधार बनता है जिनकी लंबे समय से इच्छा थी
  • आगे संभावित कामों में ये शामिल हैं
    • HDR सहित सही color handling
    • GPU पर path rendering
    • glyph rendering शामिल होने की संभावना
    • main thread के बाहर rendering
    • पुराने और कम powerful devices पर performance improvement
  • कुछ items short-term और mid-term work का focus बनेंगे
  • नए renderer में और features आने वाले हैं, और users इसे खुद test करके बता सकते हैं कि यह काम करता है या नहीं

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

1 टिप्पणियां

 
GN⁺ 2024-01-30
Hacker News की राय

  • बहुत पहले, शायद 2010 के आसपास, ऐसा लगता है कि एक experimental HTML renderer था जो browser के अंदर GTK apps चलाता था और UI को सामान्य HTML+CSS से बनाता था
    उस समय यह सचमुच चौंकाने वाला था, और शायद Atom, VS Code, Electron, और शायद NodeJS के आने से भी पहले की बात थी
    पता नहीं वह renderer अभी भी बचा है या नहीं

    • क्या आप Broadway की बात कर रहे हैं?
      https://docs.gtk.org/gtk4/broadway.html
      https://www.phoronix.com/news/GTK4-Broadway-Being-Used
      मुझे नहीं लगता था कि यह mainstream/official backend है, लेकिन यह अभी भी मौजूद है और Gtk4 पर भी port हो चुका है
    • यह मिलती-जुलती चीज़ों की तुलना में HTML और CSS का ज़्यादा इस्तेमाल तो करता है, लेकिन इसे सामान्य HTML+CSS कहना मुश्किल है
      क्योंकि इसका behavior ज़्यादा उस pure canvas approach जैसा है, जिसमें browser द्वारा दी जाने वाली लगभग हर चीज़ छोड़कर सब कुछ शुरू से फिर बनाया जाता है
      सही behavior परखने के मापदंड आम तौर पर ये हैं: (a) browser scroll का उपयोग, (b) browser text rendering का उपयोग, (c) links को वास्तविक elements की तरह handle करना; Broadway इन तीनों में fail होता है
      यह scroll को फिर से implement करता है, text को server पर render करके image के रूप में भेजता है, और link पर click करने की कोशिश करने पर ऐसा लगता है कि सचमुच रुक जाता है
      इसके अलावा text input भी शायद केवल key events का उपयोग करता है, इसलिए IME composition पूरी तरह टूट जाता है, और keyboard navigation भी native नहीं बल्कि संभवतः GTK-side का होता है
      accessibility tree भी सार्थक रूप से उपलब्ध नहीं करा पाता
      tech demo या सीमाएँ स्वीकार करने वाले personal use के लिए ठीक है, लेकिन public distribution के लिए अनुपयुक्त है और मूलतः थोड़े-से DOM use के साथ RDP/VNC जैसी चीज़ के करीब है
      यह भी याद रखना चाहिए कि पूरा code server पर चलता है
    • GTK3 के हिसाब से इसे HTML renderer कहना थोड़ा ज़्यादा होगा
      असल में यह pixel data को canvas element में stream करने का तरीका है, इसलिए web viewer लगे हुए VNC जैसा ही है
      https://imgur.com/a/2EDZ2Ti
    • इसका नाम Broadway है: https://docs.gtk.org/gtk4/broadway.html
    • पहले broadway के साथ Docker के अंदर चलने वाला एक छोटा proof of concept बनाया था, और यह काफी अच्छा चला
      https://github.com/moondev/gtk3-docker
      मेरा use case था browser के अंदर browser चलाकर, port forwarding या proxy के बिना Kubernetes clusterip services के साथ आसानी से interact करना
      एक और शानदार उदाहरण है virt-manager चलाकर gtk virt-viewer से VM run करना और browser में उसे control करना
      https://github.com/m-bers/docker-virt-manager

  • उम्मीद है GTK title bar में widgets डालने वाले trend को follow नहीं करेगा
    कुछ हिस्से drag होते हैं और कुछ नहीं, और app name और file name दिखाने की जगह भी कम हो जाती है
    यह शिकायत सिर्फ GTK तक सीमित नहीं है

    • क्या वह trend gtk/gnome ने ही शुरू नहीं किया था?
    • GNOME में यह होना ही काफी खराब है; उम्मीद है GTK में कोई और गलती नहीं होगी

  • pixel-level सटीक fractional scaling, अच्छा है, वाह!

    • 10 साल से भी ज़्यादा समय तक GTK कहता रहा कि fractional scaling “असंभव” है, और GTK developers Wayland protocol में fractional scaling को रोकते रहे; आखिरकार इस क्षेत्र में Qt के साथ feature parity आ गई
      अब बस Wayland में इसका सही support हो जाए, तो लगता है सभी major Linux desktop environments में HiDPI support संभव हो जाएगा
    • blog post की व्याख्या थोड़ी confusing है
      उसमें कहा गया है कि 1200×800 window को 125% पर scale करने पर unified renderer compositor को 2400×1600 image downscale करने देने के बजाय 1500×1000 framebuffer का उपयोग करता है
      मेरी समझ में इसका मतलब यह है कि 125% scale के कारण screen पर 1500×1000 pixels में draw होने वाली window application pixels के हिसाब से 1200×800 होती है
      OpenGL और Vulkan floating point में render करते हैं, इसलिए coordinate transform के जरिए सीधे ऐसे buffer में draw किया जा सकता है जिसे screen पर 1:1 render किया जा सके
      अगर यह सही है, तो आखिरकार यह sensible तरीका लगता है

  • क्या कोई सच में समझता है कि Linux पर desktop environments कैसे काम करते हैं? मुझे तो ठीक से नहीं पता
    बस लगता है कि वे धीरे-धीरे और ज्यादा जटिल और पैबंद लगे हुए होते जा रहे हैं

    • X Window System मूल रूप से इस बात पर गलत दांव था कि GUI और computer hardware कैसे evolve होंगे
      client/server architecture आखिरकार उस highly integrated graphics processing model के बिल्कुल उलट था, जहाँ हम पहुँचे
      X11 को जल्दी छोड़कर नुकसान कम करने के बजाय, Unix vendors और open source दोनों ही बहुत लंबे समय तक सड़े हुए नींबुओं के ट्रक से lemonade बनाने की कोशिश करते रहे
      इसलिए Linux GUI इतना पीछे रह गया
      Apple X11 से बंधा नहीं था और उसने integrated model अपनाया, इसलिए वह Unix GUI को तेजी से आगे बढ़ा सका; और अब यह बात खास तौर पर दिखती है कि वह अपना GPU तक design करता है
    • उस तरफ GNOME leading player के करीब है
      देखना दिलचस्प होगा कि Wayland architecture कितना बड़ा असर डालेगा, और क्या सच में GNOME-only apps पैदा होंगे

  • अच्छा होगा अगर कोई ansi text renderer हो
    ताकि मैं अपने xterm के अंदर GTK program चला सकूँ, और वैकल्पिक रूप से उसमें थोड़ा sixel भी जोड़ना चाहूँगा

    • आजकल ज़्यादातर GTK apps काफ़ी मिलते-जुलते दिखते हैं
      sidebar, title bar में कुछ actions, और detail-view structure
      Mac apps, “Modern” Windows apps, और mobile apps भी कुछ ऐसे ही हैं
      सोचता हूँ कि क्या UX toolkit पूरी तरह declarative और semantic हो सकता है
      यानी high level पर “master/detail view, इन fields वाली list view, कुछ actions चाहिए” जैसा बताया जाए, बिना position या style दिए, और वह अपने-आप सही system widgets इस्तेमाल करे
      उसके ऊपर थोड़ा CSS या native widgets में निकलने का escape hatch जोड़ा जा सकता है
      browser, WYSIWYG editor, और media viewer न होने वाले लगभग हर app पर यह ढांचा फिट हो सकता है, और मुख्य बात यह है कि ऐसे description से TUI आसानी से generate किया जा सकता है
    • दूसरे comments में बताए गए broadway और carbonyl को मिलाएँ तो कुछ हद तक ऐसा ही बनता है
      https://github.com/fathyb/carbonyl
      https://i.imgur.com/pIQ4K7Q.png

  • अगर https://wgpu.rs/ इस्तेमाल किया होता तो DirectX और Metal मुफ्त में मिल जाते :)

  • यह काम वाकई मज़ेदार लगता है
    antialiasing वाला हिस्सा पढ़ते समय मुझे लगा कि game engines की तरह signed distance fields arbitrary scale पर font rendering में भी अच्छी तरह काम कर सकते हैं
    Valve ने इस विषय पर एक अच्छा paper भी निकाला था
    game renderer के UI code या decal rendering में कई बढ़िया techniques हैं जो GUI code में भी काम आ सकती हैं

  • समझ नहीं आता कि performance degradation क्यों स्वीकार्य माना जा रहा है
    मैं अपने ज़्यादातर काम पुराने hardware पर करता हूँ, और अगर ये features बंद किए जा सकें तो मैं बंद करना चाहूँगा; हो सकता है मेरे GPU पर ये support भी न हों

    • “नहीं, नया renderer अभी तेज़ नहीं है” में मेरे हिसाब से अहम शब्द अभी है
      अगर साफ़ performance degradation दिखे तो GSK_RENDERER=gl इस्तेमाल किया जा सकता है
      Microsoft, Apple, Google होते तो शायद इस पर चर्चा तक नहीं करते
      शायद Microsoft कहता “पुराने API को भूल जाइए, यह रहा नया API”, Apple कहता “${WEIRD_NAME} से यह अनिवार्य है”, और Google कहता “आपको वह update नहीं मिलेगा”
    • GL में अगर संयोग से fast path छूट जाए तो यह हैरान कर देने वाली धीमी हो सकती है, और उल्टा उस path पर चल जाए तो हैरान कर देने वाली तेज़ भी हो सकती है
      लेकिन निराशाजनक बात यह है कि Vulkan renderer बस मौजूदा GL renderer जैसी ही performance तक पहुँचता है
      यह संकेत जैसा लगता है कि समस्या 3D API में नहीं, बल्कि caller side में है
      implementation के दौरान लगातार performance track करके iterative सुधार करने चाहिए थे; “architectural purity” पर भरोसा करना शायद अच्छा विचार नहीं था
    • मैं performance regression को सिर्फ़ तब स्वीकार करता हूँ जब पिछला implementation सचमुच गलत था, न कि केवल इसलिए कि वह पुराना था या किसी trendy framework/technology में फिर से लिखना ज़रूरी था
    • ये renderers default नहीं हैं और शायद आगे भी default नहीं बनेंगे
      मैंने कभी नहीं देखा कि immediate-mode rendering API को retained mode में बदलकर वह तेज़ हो जाए
      किसी न किसी तरह संभव तो होगा, लेकिन इसके लिए बहुत बड़ा काम लगेगा, और pathological cases ठीक करने के लिए API client side पर भी बदलाव चाहिए होंगे
    • GNOME dev team, और व्यापक रूप से GTK पक्ष, इस पर ज़्यादा ध्यान देता नहीं लगता
      याद पड़ता है कि उनमें से ज़्यादातर महंगे MacBook इस्तेमाल करते हैं, इसलिए कई समस्याएँ “मेरे computer पर तो ठीक है” कहकर नज़रअंदाज़ हो जाती हैं
      उदाहरण के लिए font rendering की कई समस्याएँ Retina display को प्रभावित नहीं करतीं

  • उम्मीद है यह कड़वा न लगे, लेकिन ज़्यादातर अच्छे graphics engine developers पहले ही ऐसे renderers बना चुके हैं जो open source GUI toolkit renderers से कई पीढ़ी आगे हैं
    हममें से कई लोग open source desktop पर सचमुच next-generation rendering ला सकते हैं, लेकिन वे game development companies में काम करते हैं और वही उनकी रोज़ी-रोटी है
    open source stack में योगदान देने का समय नहीं है
    अगर community ऐसे developers को नियमित रूप से भुगतान करने के लिए budget संगठित कर सके, तो renderer और toolkit updates में बड़ा बदलाव आ सकता है
    यही बात दूसरे open source apps पर भी लागू होती है

    • मैंने अतीत में GPU-targeted GUI renderers कुछ बार implement किए हैं, उदाहरण के लिए यह: https://github.com/Const-me/Vrmac?tab=readme-ov-file#vector-graphics-engine https://github.com/Const-me/Vrmac/blob/master/Vrmac/Draw/VAA.md
      2D graphics में game engines के साथ बहुत कम समानता होती है
      2D में आमतौर पर input के रूप में Bezier और दूसरे splines आते हैं, overdraw बहुत होता है, और user-provided textures की वजह से VRAM memory management जटिल हो जाता है
      इसके उलट game engines dynamic lighting, volumetric effects, dynamic environments जैसी कठिन समस्याएँ हल कर रहे होते हैं, जिनका 2D renderer से संबंध नहीं है
    • इस दावे को लेकर मैं थोड़ा skeptical हूँ
      मुझे लगता है कि game UI toolkits और desktop GUI frameworks अलग-अलग दुनिया में रहते हैं, जहाँ expectations अलग हैं
      अपने career में दोनों इस्तेमाल करने के अनुभव से, GTK/Qt आम तौर पर operating system integration, accessibility features, keyboard navigation, copy/paste जैसी capabilities को अच्छे या बहुत अच्छे तरीके से handle करते हैं
      Game UI toolkits को इन चीज़ों की जरूरत नहीं होती, इसलिए वे अक्सर इन्हें पूरी तरह छोड़ देते हैं, और इसके बजाय performance, themes, game engine integration पर focus करते हैं
      सैद्धांतिक रूप से कहा जा सकता है कि renderer इन हिस्सों से independent है, लेकिन व्यवहार में यह पूरी तरह सच नहीं है
      Budget सीमित होने पर किस feature पर समय लगाया जाए, यह भी अलग होता है
      बहुत तेज़ और accurate renderer desktop GUI frameworks में उतना महत्वपूर्ण नहीं है जितना game UI toolkits में है
    • उन game engines में से कितनों के पास इतना abstraction level है कि उन्हें PDF या SVG backend से swap किया जा सके?
      कितने CMYK और print units support करते हैं?
      यह तो बस उन चीज़ों की सतह भर है जो GUI renderer के लिए जरूरी हैं लेकिन game engine के लिए नहीं
      मुझे इस बात पर बहुत संदेह है कि game developers मिलकर Skia से कहीं तेज़, और फिर भी बहुत सारी functionality sacrifice किए बिना, कुछ झटपट बना सकते हैं
    • यहाँ जिस community की बात हो रही है, वह आखिरकार आप जैसे लोग ही हैं
      ऐसे लोग जिन्हें अपनी रोज़ी-रोटी चलानी है, लेकिन software इस्तेमाल करके और कभी-कभी code contribute करके जितना संभव हो उतना योगदान देते हैं
      बेशक अगर community funding जुटा सके तो शानदार होगा, लेकिन उस coordination work से भी किसी की रोज़ी-रोटी नहीं चलती
      मैं open source/free software को पसंद करता हूँ, इसके होने के लिए आभारी हूँ और जब संभव हो contribute भी करता हूँ, लेकिन मैं लंबे समय से इसे विशेषाधिकार प्राप्त लोगों की pursuit मानता आया हूँ
      आपके पास free time होना चाहिए, और आप उस free time को ऐसे काम में लगा सकें जिससे आपका living standard न बढ़े, और आप यह लगातार कर सकें
    • उस बात को लेकर मैं काफी skeptical हूँ
      मैं game industry में काम करता हूँ, और 3D renderers बहुत अच्छे हैं, लेकिन मैंने ऐसा 2D UI renderer नहीं देखा जिसे competitive कहा जा सके
      paths और patterns rendering के लिए आप क्या इस्तेमाल कर रहे हैं?