Wayland compositor और window manager का अलगाव

 (isaacfreund.com)
2 पॉइंट द्वारा GN⁺ 2026-03-16 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • मौजूदा Wayland वातावरण में compositor और window manager एक ही प्रोग्राम में जुड़े हुए होते थे, लेकिन river 0.4.0 इन्हें अलग processes में विभाजित करता है
  • नया river-window-management-v1 protocol window manager को window placement, key bindings जैसी policies पर पूरा अधिकार देता है, जबकि frame perfection और performance को बरकरार रखता है
  • यह संरचना input latency के बिना काम करती है, और जटिल tile layouts में भी atomic state updates के जरिए साफ़-सुथरी rendering सुनिश्चित करती है
  • अलग की गई संरचना की वजह से window manager को स्वतंत्र रूप से develop और restart किया जा सकता है, और high-level languages में implement करना भी आसान हो जाता है
  • यह दृष्टिकोण Wayland ecosystem में window managers की विविधता बढ़ाने को प्रोत्साहित करता है, और river पहले से ही 15 से अधिक compatible managers को support करता है

Wayland की पारंपरिक संरचना और river का अलगाव वाला दृष्टिकोण

  • पारंपरिक Wayland compositor display server, compositor, और window manager — इन तीन भूमिकाओं को एक ही process में एकीकृत करता था
    • display server input events को route करता है और kernel को display buffer सौंपता है
    • compositor कई windows के buffers को मिलाकर अंतिम स्क्रीन तैयार करता है
    • window manager window placement, key bindings जैसी user policies को संभालता है
  • X11 संरचना में display server एक अलग process के रूप में मौजूद होता था, जिससे अनावश्यक round-trip communication और latency पैदा होती थी
  • Wayland ने इसे हल करने के लिए server और compositor को एकीकृत किया, लेकिन window manager को भी साथ जोड़ना अनिवार्य नहीं है
  • river इस जुड़ाव को तोड़कर window manager को एक अलग प्रोग्राम के रूप में अलग करता है

river-window-management-v1 protocol के design principles

  • इसे इस तरह design किया गया है कि window manager के पास अधिकतम control हो, लेकिन Wayland के फायदे भी बने रहें
  • हर frame या input event पर round-trip communication की ज़रूरत नहीं पड़ती, इसलिए input latency नहीं होती
  • frame perfection बनाए रखी जाती है: जब कोई window खुलती है या उसका size बदलता है, तो बिना gap या overlap के screen update सुनिश्चित होता है
    • rendering को तब तक रोका जाता है जब तक सभी windows नया buffer submit न कर दें, लेकिन तय समय से अधिक होने पर timeout के साथ आगे बढ़ा जाता है
  • application जितनी अच्छी तरह implement की गई हो, उतनी ही पूर्ण frame synchronization संभव होती है

state machine आधारित window management संरचना

  • protocol state को window management state और rendering state में अलग करता है
    • window management state: window size, fullscreen status, keyboard focus, key bindings आदि
    • rendering state: window position, order, decorations, crop आदि
  • बदलावों को atomic updates (manage/render sequence) के रूप में समूहित करके process किया जाता है
  • compositor sequence की शुरुआत करता है, और जब state changes नहीं होते तब window manager idle state में बना रहता है
  • यह संरचना river-classic, sway आदि में पहले से मौजूद अवधारणाओं को स्पष्ट और औपचारिक रूप देती है

अलग संरचना के फायदे

  • window manager developers पूरा compositor implement किए बिना सिर्फ policy पर focus कर सकते हैं
  • debugging और restart आसान हो जाते हैं, और window manager crash होने पर session समाप्त नहीं होता
  • garbage-collected languages में लिखने पर भी performance गिरती नहीं, और frame delay के बिना काम होता है
  • पहले से ही 15 से अधिक river-compatible window managers मौजूद हैं, और X11 जैसी विविधता बढ़ने की उम्मीद है

सीमाएँ और आगे की योजना

  • फिलहाल यह protocol सिर्फ 2D desktop environments को support करता है, VR जैसी चीज़ें अभी supported नहीं हैं
  • जटिल visual effects (जैसे हिलती-डुलती windows) इसकी scope से बाहर हैं, हालांकि simple animations संभव हैं
  • आगे custom shaders support पर विचार हो रहा है, लेकिन यह short-term plan नहीं है
  • river 0.4.0 रोज़मर्रा के उपयोग के लिए पर्याप्त है, और 1.0.0 version से पहले UX improvements की योजना है
  • development जारी रखने के लिए liberapay, GitHub Sponsors, Ko-fi के जरिए समर्थन की अपील की गई है

उदाहरण और gallery

  • river पर चलने वाले कई window managers के उदाहरण दिए गए हैं
    • Canoe: एक क्लासिक stacking window manager
    • reka: Emacs-आधारित window manager
    • tarazed: focused desktop environment
    • rhine: recursive, modular window management और animation support
  • इनके अलावा भी कई river-compatible window managers मौजूद हैं

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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.