Wayland vs. X11 इनपुट लेटेंसी बहस के ठोस आंकड़े

 (mort.coffee)
2 पॉइंट द्वारा GN⁺ 2025-01-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Fedora Workstation 41·GNOME 47 वातावरण में कर्सर इनपुट लेटेंसी को 240 FPS स्लो-मोशन में रिकॉर्ड करके Wayland और X11 की तुलना की गई
  • माउस के चलना शुरू होने वाले फ्रेम से लेकर कर्सर के नई स्थिति में दिखने वाले फ्रेम तक गिनने की विधि से, Wayland 16 बार और X11 16 बार की फ्रेम लेटेंसी दर्ज की गई
  • GNOME X11 का औसत 4 फ्रेम·16.7ms·2.4 स्क्रीन रिफ्रेश, जबकि GNOME Wayland का औसत 5.5625 फ्रेम·23.2ms·3.3 स्क्रीन रिफ्रेश मापा गया
  • इस सिस्टम में Wayland ने X11 की तुलना में औसतन लगभग 6.5ms अधिक कर्सर लेटेंसी दिखाई, और यह अंतर लगभग एक स्क्रीन रिफ्रेश के करीब था
  • नतीजे सिर्फ GNOME/AMD संयोजन में कर्सर लेटेंसी के अंतर को दिखाते हैं; यह इस बात का प्रमाण नहीं है कि गेम या सामान्य ग्राफिक्स एप्लिकेशन में Wayland इनपुट लेटेंसी अधिक है

यह माप क्यों किया गया

  • एक Linux उपयोगकर्ता की Wayland इनपुट लेटेंसी शिकायत पर आधारित Wayland Cursor Lag: Just give me a break already... पोस्ट के बाद, व्यक्तिपरक अनुभव के बजाय ठोस आंकड़े पाने के लिए यह प्रयोग किया गया
  • Wayland का समग्र अनुभव संतोषजनक होने के बावजूद, X11 की तुलना में कर्सर लेटेंसी अधिक लगने की धारणा ही इस प्रयोग की शुरुआत थी
  • पहले की पोस्ट में 90 FPS फोन कैमरा एक स्क्रीन रिफ्रेश स्तर के अंतर को पहचानने के लिए पर्याप्त नहीं माना गया, इसलिए 240 FPS रिकॉर्डिंग मोड का उपयोग किया गया

मापने की विधि

  • फोन कैमरे से स्क्रीन, डेस्क, माउस कर्सर, माउस और हाथ को एक साथ रिकॉर्ड करते हुए उंगली से माउस को बार-बार झटका दिया गया
  • GNOME Wayland सेशन में 16 रिकॉर्डिंग के बाद, GNOME X11 सेशन में लॉगिन करके उसी तरीके से 16 रिकॉर्डिंग की गईं
  • रिकॉर्ड किए गए वीडियो को ffmpeg -i <input file> %04d.jpg कमांड से JPEG फ्रेम में बदला गया
  • फ्रेम लेटेंसी को निम्न मानदंडों के अनुसार गिना गया
    • जिस पहले फ्रेम में माउस का हिलना दिखे, वहीं से गिनती शुरू की गई
    • जिस पहले फ्रेम में कर्सर नई स्थिति में स्पष्ट रूप से हिला हुआ दिखे, वहीं तक गिना गया
    • शुरुआती और अंतिम दोनों फ्रेम गिनती में शामिल किए गए
    • उदाहरण के लिए, अगर माउस 1045वें फ्रेम में हिले और कर्सर 1047वें फ्रेम में हिले, तो उसे 3 फ्रेम लेटेंसी के रूप में दर्ज किया गया

टेस्ट वातावरण

  • प्रयोग का हार्डवेयर और सॉफ्टवेयर इस प्रकार था
    • डिस्ट्रो: Fedora Workstation 41
    • GNOME संस्करण: 47
    • CPU: AMD Ryzen 9 5950X
    • GPU: AMD Radeon RX 7900XT
    • मॉनिटर: Gigabyte M32U, 4K IPS, 144.99Hz, बिना DPI scaling
    • माउस: Logitech G502 Lightspeed
    • कैमरा: iPhone 15 Pro, स्लो-मोशन 240 FPS

मापन की सीमाएं

  • 144Hz स्क्रीन पर 240 FPS भी प्रति स्क्रीन रिफ्रेश 2 से कम कैमरा फ्रेम देता है, इसलिए रैंडम उतार-चढ़ाव पैदा होता है
  • पिक्सेल तुरंत स्विच नहीं होते, इसलिए ऐसे अस्पष्ट फ्रेम मौजूद थे जिनमें कर्सर नई स्थिति में बहुत हल्का दिखना शुरू होता है
  • भले ही कर्सर पूरी तरह उजला न हुआ हो, अगर वह नई स्थिति में स्पष्ट दिखे तो उसे कर्सर की मूवमेंट माना गया
  • iPhone वीडियो में कुछ डुप्लिकेट फ्रेम शामिल थे, जिनका कारण पता नहीं चला
    • डुप्लिकेट फ्रेम को भी एक फ्रेम के बराबर समय बीतने के रूप में मानकर सामान्य फ्रेम की तरह गिना गया
  • इन कारणों से नतीजों में अनिश्चितता आती है, लेकिन माना गया कि Wayland और X11 दोनों पर इनका असर समान होगा, और पर्याप्त डेटा होने पर औसत में संतुलित हो जाएगा
  • GNOME के अलावा अन्य Wayland compositors और AMD के अलावा अन्य GPU drivers का परीक्षण नहीं किया गया, इसलिए दूसरे संयोजनों में परिणाम अलग हो सकते हैं

मापन के नतीजे

  • GNOME X11 के 16 मापन मान 5, 4, 3, 4, 5, 4, 6, 5, 1, 4, 4, 4, 3, 4, 4, 4 फ्रेम थे
    • औसत: 4 फ्रेम
    • लेटेंसी समय: 16.7ms
    • स्क्रीन रिफ्रेश: 2.4 बार
  • GNOME Wayland के 16 मापन मान 6, 5, 6, 5, 5, 6, 6, 4, 8, 6, 5, 5, 5, 6, 5, 6 फ्रेम थे
    • औसत: 5.5625 फ्रेम
    • लेटेंसी समय: 23.2ms
    • स्क्रीन रिफ्रेश: 3.3 बार
  • इस सिस्टम में Wayland ने X11 की तुलना में औसतन लगभग 6.5ms अधिक कर्सर लेटेंसी दिखाई
  • यह सांख्यिकीय रूप से महत्वपूर्ण है या नहीं, इसका ठीक विश्लेषण करने की विशेषज्ञता नहीं होने की बात कही गई, लेकिन मापे गए मानों में अंतर स्पष्ट और लगातार दिखता है
  • यह अंतर लगभग एक स्क्रीन रिफ्रेश के बराबर था, हालांकि यह संयोग है या नहीं, यह स्पष्ट नहीं है

निष्कर्ष और व्याख्या की सीमा

  • यह प्रयोग दिखाता है कि खास हार्डवेयर पर X11 और Wayland के बीच इनपुट लेटेंसी का अंतर मौजूद हो सकता है, और यह कुछ उपयोगकर्ताओं को महसूस होने लायक बड़ा हो सकता है
  • समस्या की सीमा और आकार को स्पष्ट समझने के लिए अधिक विविध हार्डवेयर और डिस्प्ले refresh rate पर अतिरिक्त परीक्षण की जरूरत है
  • इस अंतर का आकार उपयोग किए जा रहे compositor और डिस्प्ले refresh rate जैसे कारकों पर निर्भर कर सकता है
  • अतिरिक्त प्रयोगों में बहुत समय लगेगा, इसलिए संभव है कि उन्हें सीधे न किया जाए
  • यह टेस्ट यह नहीं दिखाता कि Wayland में कुल मिलाकर X11 से अधिक इनपुट लेटेंसी होती है
    • खास तौर पर, यह गेम में Wayland इनपुट लेटेंसी अधिक होने का प्रमाण नहीं है
    • अतिरिक्त लेटेंसी सिर्फ कर्सर-विशिष्ट हो सकती है
    • समझ यह है कि कर्सर को सामान्य ग्राफिक्स एप्लिकेशन से काफी अलग तरीके से प्रोसेस किया जाता है
    • गेम में Wayland, X11 से अधिक इनपुट लेटेंसी दिखाता है या नहीं, इसके लिए अलग परीक्षण की जरूरत है

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

1 टिप्पणियां

 
GN⁺ 2025-01-27
Hacker News की राय

  • शानदार तरीका है। लोग जिन चीज़ों को और प्रयोग करके सत्यापित कर सकते हैं, उनके बारे में बहुत बार बस अटकलें लगा देते हैं। वैज्ञानिक पद्धति सीखने के बाद से मैं हमेशा “चलो कोई experiment design करते हैं” वाली दिशा में खिंचता रहा हूँ
    Wayland में अतिरिक्त delay क्यों आता है, यह नहीं पता, लेकिन X11 के शुरुआती दिनों में computer community में मौजूद रहे व्यक्ति के तौर पर कह सकता हूँ कि शुरू से ही screen delay को लेकर शिकायतें लगातार आती थीं। चाहे cursor response हो या xterm scrolling, दोनों में यही था
    जब “workstation” आए थे, तो कुछ में केवल mouse के लिए अलग display hardware भी होता था, ताकि frame के अंदर mouse render करने की delay कम की जा सके। बदनाम XOR patent भी था: https://patents.google.com/patent/US4197590
    ऐसी शिकायतों की वजह से keyboard/mouse input से लेकर screen पर उसके दिखने तक के code path को लगातार “और तेज़, और कम delay” बनाने के तरीकों के लिए परखा जाता रहा। X11 की तुलना में Wayland अपेक्षाकृत “नया” है, इसलिए उतने लंबे समय तक tested नहीं हुआ है, लेकिन उम्मीद है कि लोग इसे सुधारते रहेंगे

    • display device में, आमतौर पर GPU के किसी हिस्से में, अब भी mouse के लिए explicit display hardware होता है, जो आज cursor plane के रूप में मौजूद है। बाद में इसका और general रूप overlay plane भी आया
      plane को बाकी screen दोबारा draw किए बिना update या reposition किया जा सकता है। सामान्य screen image base plane पर होती है, और cursor movement करीब-करीब नए plane position को commit करने जैसा काम है
      यहाँ इस्तेमाल किए गए Wayland server GNOME Mutter द्वारा जो input delay जोड़ी जा रही है, वह शायद input sampling और commit timing strategy की समस्या हो सकती है। अलग-अलग servers की strategies और priorities अलग होती हैं, जिससे pros और cons बनते हैं
      Wayland एक protocol है, इसलिए सामान्य cursor positioning process में शामिल नहीं होता। इसलिए यह issue पूरी तरह display server की internal implementation और optimization का क्षेत्र है। protocol level पर बस client को cursor image set करने देना और client को cursor position बताना जैसा काम होता है
    • पहले XFree86 और Xorg SIGIO handler के अंदर pointer को सीधे update करते थे। लेकिन अब यह बहुत पुरानी बात है, और आजकल इस area में Wayland और Xorg में बहुत बड़ा फर्क होने की उम्मीद नहीं करूँगा
      याद है कि Xorg में glamour आने के साथ स्थिति खराब होने लगी थी। cursor rendering path signal handler में चलाने के लिए safe नहीं रह गया, और OpenGL based होने पर तो ऐसा होना स्वाभाविक था, जिससे delay और खराब हो गई
      पहले Linux machine thrashing में भी हो तो mouse pointer responsive रहता था, और यह अंदाज़ा लगाने का भरोसेमंद संकेत था कि kernel अटका है या नहीं। अगर pointer बहुत जल्दी responsive न हो, तो IDE/PATA host पर hdparm से unmask irq on करना पड़ता था। XFree86 में unresponsive pointer बहुत उपयोगी संकेत था कि कुछ गलत है या configuration गलत है; वे दिन याद आते हैं
    • Wayland कितने साल का है? इस रफ्तार से तो कब्र में “वसंत का सपना” पढ़ रहा होगा
      मैं समझता हूँ कि free software पर शिकायत करना अलग बात है, लेकिन यह बहुत लंबे समय से बदतर दिशा में forced transition बन गया है। Wayland adoption सभी input और display requirements में लगभग सार्वभौमिक रूप से बेहतर होने की धारणा पर होना चाहिए था
      Intel, AMD, Nvidia, Arm manufacturers को usable desktop Linux के लिए consortium बनाकर पूरी ताकत लगानी चाहिए। सरकारों को भी ऐसा करना चाहिए। क्योंकि secure Linux desktop वास्तव में संभव है, और CPU व 3D features, advanced vector/computer hardware दिखाने का सबसे तेज़ रास्ता है
      Wayland उस दौर में आया जब Windows अपने भयानक tiled UI से खुद को नुकसान पहुँचाने की कोशिश कर रहा था, और Apple आम x86 के लिए macOS जारी करने पर मिल सकने वाली अतिरिक्त market cap को हठपूर्वक ठुकरा रहा था; इस तरह उसने Linux desktop की delay और बढ़ा दी
    • “mouse के लिए explicit display hardware था जिससे delay कम हुई” — यह आज भी वैसा ही है। mouse cursor को window compositor की swapchain से independent sprite/overlay के रूप में render किया जाता है। ऐसा न हो तो खासकर 60Hz पर delay बहुत साफ दिखती है
      trick तब चाहिए होती है जब window या icon drag कर रहे हों; तब swapchain delay दिखने लगती है। कुछ window compositors सोचते हैं कि high refresh rate की वजह से delay कम दिखती है और अब इस पर ध्यान नहीं देते; उदाहरण के लिए macOS ऐसा है, और Windows लगता है drag के दौरान software mouse cursor पर switch करता है
    • GNOME में unredirection support है, इसलिए यह कहना मुश्किल है कि यह test actual game performance पर लागू होता है
      fullscreen apps को compositor से होकर गुजरने या उसे bypass करने वाला fast path लेना चाहिए

  • इस तरह की frame-by-frame analysis में ffmpeg इस्तेमाल करने वाले लोग ffmpeg -skip_frame nokey -i file -vsync 0 -frame_pts true out%d.png से video के हर frame का display timestamp पा सकते हैं। यह सिर्फ frames dump करके timestamps calculate करने से ज्यादा accurate है
    web browser में भी video चलाते हुए requestVideoFrameCallback() इस्तेमाल करके कुछ ऐसा ही किया जा सकता है। हालांकि अगर computer सभी frames को पर्याप्त तेज़ी से decode नहीं कर पाता, तो .playbackRate कम करनी पड़ सकती है
    144Hz screen पर Wayland का X11 से average लगभग 6.5ms धीमा होना, और यह फर्क लगभग एक screen refresh के बराबर होना, संयोग नहीं भी हो सकता। अगर delay लगभग 1/144 second है, तो सामान्य 60Hz monitor पर यह 1/60 second हो सकती है। training के बिना इसे consciously notice करना कठिन है, लेकिन ज्यादातर लोग इसे समझा न सकें तब भी “feel” कर सकते हैं

    • अनुमान लगाऊँ तो “real” numbers शायद 2.5 frames और 3.5 frames के करीब होंगे। mouse छूने के moment और screen refresh के बीच random phase की वजह से average आधा frame, और इसके ऊपर cursor movement के लिए 2 frames या 3 frames जुड़ते हैं। हर set से lower outliers हटाएँ तो value उसके काफी करीब आ जाती है
      बेशक कई users के लिए 125Hz mouse polling rate भी confounding factor है, लेकिन इस case में 1KHz mouse इस्तेमाल किया गया था
      7ms का difference बुरा नहीं है, लेकिन 16.6ms का difference काफी बड़ा लगने लगता है। व्यक्तिगत रूप से, मुझे लगता है computer को 1.6-frame latency target करने की कोशिश करनी चाहिए। random phase का आधा frame, एक frame, और थोड़ा processing time
    • low-latency terminal में साधारण typing जैसे कामों में भी बड़ा महसूस होने वाला improvement होता है
    • mouse movement और screen के बीच buffering का एक extra frame जुड़ गया है, यह लगभग निश्चित लगता है। vertical sync ऐसा कर सकता है, लेकिन double buffering alone से भी vertical sync संभव होनी चाहिए

  • नतीजे compositor, GPU और settings के हिसाब से बदलेंगे। X11 में Linux desktop systems द्वारा इस्तेमाल होने वाला X server implementation व्यावहारिक रूप से सिर्फ एक ही है, इसलिए ऐसा फर्क कम होता है
    अभी भी कई compositor/GPU combinations में hardware cursor plane न मिल पाने की समस्या हो सकती है, और अगर ऐसा है तो delay में ऐसा फर्क आसानी से आ सकता है

  • आज पता चला कि Wayland को पहले ही 16 साल हो चुके हैं। कुछ साल बाद Wayland की उम्र उतनी हो जाएगी जितनी X की थी जब Wayland आया था, लेकिन लगता है उसे अब भी साधारण या X से कमतर माना जाता है

    • X की पहली release जून 1984 में हुई थी और Wayland पहली बार 2008 में आया था, इसलिए Wayland को उतनी ही उम्र का होने के लिए 2032 तक पहुँचना होगा। जब लोग शिकायत करते हैं कि Wayland साधारण है या “X जितना अच्छा नहीं है”, तो आम तौर पर उनका मतलब होता है कि “Wayland $very_specific_feature support नहीं करता” या “मेरे graphics card manufacturer का proprietary driver Wayland पर पर्याप्त test नहीं हुआ है, यह दुखद है”
      ऐसी शिकायतों में से करीब 99.999% उन लोगों से आती हैं जो 1) खुद काम नहीं करते, 2) काम करने में रुचि या क्षमता नहीं रखते, और 3) यह समझते या मानते नहीं कि Wayland और X developers ज्यादातर वही लोग हैं और वे अब X11 पर काम नहीं करना चाहते
      इस बहस में मेरी कोई खास हिस्सेदारी नहीं है, लेकिन दूसरों द्वारा मुफ्त में दिए गए software का इस्तेमाल करते हुए Wayland की शिकायतें देखकर थक गया हूँ। अगर Wayland को लेकर इतनी शिकायतें हैं, तो अब तक लोग मिलकर X को maintain और improve कर सकते थे, और अगर शिकायतें व theory सही होतीं तो Wayland को पीछे छोड़ सकते थे
      अजीब बात है कि X open source है और उसे कभी भी fork किया जा सकता है; XFree86 से X.org निकलने का उदाहरण होने के बावजूद, समर्थक उसे धूल खाने के लिए छोड़ देते हैं और maintenance में कुछ नहीं करते
      अगर “Wayland X जितना अच्छा नहीं है, इसलिए हमने एक modernized X fork बनाया है जिसे कोई भी इस्तेमाल कर सकता है” जैसा परिणाम सामने आए, तो मैं उसे काफी दिलचस्पी से देखूँगा
    • नहीं, ऐसा नहीं है। X 1984 का है: https://www.talisman.org/x-debut.shtml
      यानी Wayland अभी उस समय X की उम्र का लगभग 66% ही है जब Wayland आया था, और समान उम्र तक पहुँचने के लिए Wayland की मौजूदा उम्र में 50% और समय चाहिए
    • अगर X 40 साल का है और Wayland 16 साल का, तो फर्क 24 साल है। इसलिए Wayland compositors के पास समस्याएँ polish करने के लिए 8 साल बचे हैं
      मैं अभी Plasma 6 में Wayland इस्तेमाल कर रहा हूँ और यह काफी अच्छे से काम करता है, लेकिन मेरी कोई खास requirements नहीं हैं, इसलिए उदाहरण के लिए screen reader कितना अच्छा चलता है, यह नहीं जानता
    • इन numbers को दूसरे तरीके से देखें तो इसका मतलब यह भी है कि कुछ साल बाद Wayland के successor के आने का समय हो जाएगा। यह Wayland जैसी ही वजह से आ सकता है, यानी legacy software maintain करने वाले लोगों की कमी
      उस समय तक मुझे उम्मीद है कि browser frontend stack desktop को पूरी तरह निगल चुका होगा। वैसे भी Linux पर बहुत सारे नए desktop apps आ ही नहीं रहे थे
    • Wayland उसी समय के आसपास आया था जब Windows Vista का compositor आया था। उदारता से मान लें कि अगले version Windows 7 में “अच्छा और stable” compositor आया, तो Wayland Windows से 13 साल पीछे है

  • किसी काम करने वाले solution को “ज्यादा modern, maintain करने में आसान, और future-proof” बताकर फिर से लिखने की कोशिशें अक्सर वैसी नहीं बनतीं, इसमें आश्चर्य नहीं है। आम तौर पर वे धीमी हो जाती हैं, latency बढ़ती है, और बस तेज hardware उसे संभाल लेता है; software असल में तेज नहीं हुआ होता
    ऐसा लगता है कि हर 20 साल में नई पीढ़ी पिछली पीढ़ी द्वारा कठिन काम करके बनाई गई abstractions पर बिगड़े बच्चों की तरह निर्भर रहती है और कमजोर होती जाती है। Software developers की करीब 3 generations के बाद जो बचा है वह library/framework callers हैं, और performance व optimization को ठीक से समझने वाले बहुत कम लोग हैं

    • मेरा अनुभव अलग है। कई computers को KDE 6 में upgrade करते हुए Wayland पर switch किया, तो system की overall responsiveness और हल्कापन साफ तौर पर बेहतर हुआ
      Wayland में X11 की तुलना में अभी कुछ features की कमी है, लेकिन उसके दूसरे फायदे देखते हुए मैं इतना compromise करने को तैयार हूँ
    • पुराने computers में latency कम थी, लेकिन इसके उलट कई operating systems में अगर एक app crash हो जाता था तो पूरा OS respond करना बंद कर देता था और पूरे system को reboot करना पड़ता था

  • कई Wayland compositors में keyboard, mouse और अन्य input devices को लेकर बड़ी समस्याएँ हैं। क्योंकि Wayland spec और reference implementation ने इन्हें support न करने का फैसला किया। इसलिए हर Wayland compositor अलग-अलग solution चुनता है
    आम विकल्प libei और libinput हैं, लेकिन “advanced” mouse/keyboard input को बिल्कुल support न करने के मामले भी बहुत हैं। weston ऐसा ही उदाहरण है। कोई खास Linux software किसी खास Wayland environment में चलेगा या नहीं, यह बिल्कुल पता नहीं चलता, और fragmentation गंभीर है
    X में एक मजबूत X11 reference है जो सच में सब कुछ implement करता है, इसलिए अगर कोई चीज एक जगह चलती है तो भरोसा किया जा सकता है कि दूसरी जगह भी चलेगी
    यहाँ तक कि 12 साल बाद भी visually impaired users के लिए screen reader support करने वाला कोई Wayland compositor नहीं है। यह toy-level है

    • सुना है कि color calibration support भी गायब है। पढ़ने पर लगता है कि calibration app जब measurement करना चाहता है, उस दौरान कौन-सी calibration लागू हो रही है इसे control या जानने का भी कोई तरीका नहीं है। ऊपर से client-side window decorations भी अभी बाकी हैं, जिससे पुराने security hole को ठीक करने का मौका छोड़ दिया गया
      इसलिए यह gaming के लिए भी अच्छा नहीं है, professional graphics work के लिए भी नहीं, और कमजोर eyesight वाले लोगों के लिए भी नहीं। आखिरकार इसका मतलब है कि इसे बनाने वालों से थोड़ा भी अलग users के लिए यह आम तौर पर अच्छा नहीं है
      फिर भी अगर किस्मत अच्छी हो तो शायद इसने screen tearing कम कर दी हो, जिसे मैंने कभी महसूस ही नहीं किया
    • macOS से Windows पर आने के बाद आखिरकार Windows पर ही टिक गया, और अपना leisure development time Windows में tiling window manager ecosystem के जरिए power user/developer experience बेहतर करने में लगाने लगा: https://github.com/LGUG2Z/awesome-komorebi
      इससे निकले शानदार नतीजों में से एक यह है कि लोग इस ecosystem के ऊपर accessibility workflows जोड़ रहे हैं। एक व्यक्ति voice control से tiling window manager के जरिए पूरा desktop operate करता है: https://youtu.be/fiPJLmhnnXM
    • “advanced mouse/keyboard input को बिल्कुल support नहीं करता” शायद गलत जगह दोष दे रहा है। ऐसी peripherals बनाने वाली कंपनियों को देखना चाहिए जो Linux drivers नहीं देतीं
    • GNOME के Wayland में Orca इस्तेमाल करते समय क्या कमी है?

  • GPU पर भारी load पड़ने पर, जैसे Stable Diffusion inference जैसे काम करते समय, बड़े latency spikes आते हैं। X11 के साथ A/B test तो नहीं किया, लेकिन पहले ऐसी याद नहीं है
    एक frame जितनी अतिरिक्त latency भी अच्छी नहीं है, लेकिन कभी-कभी उछलकर आने वाले latency spikes सच में बहुत परेशान करते हैं

    • खासकर अगर VRAM और system memory के बीच thrashing हो रही हो, तो यह अब भी हो सकता है। फिर भी जिज्ञासा है कि क्या Stable Diffusion process की priority कम करके देखी गई थी

  • Cursor input latency ऐसी बाधा है जो application या operating system से संतुष्टि को लगातार कम करती रहती है
    IDE text cursor latency? स्वीकार्य नहीं
    shell text cursor latency? स्वीकार्य नहीं
    GUI mouse cursor latency? स्वीकार्य नहीं
    ये सब तुरंत reject करने की शर्तें हैं

    • यह उन क्षेत्रों में से एक है जहां macOS हमेशा उत्कृष्ट रहा है, और यह बात classic Mac OS के दौर तक जाती है
      40 साल से भी ज्यादा पहले, लगभग असीम रूप से कमजोर hardware पर चलने वाला System 1 तक cursor responsiveness को सर्वोच्च प्राथमिकता देता था और सभी प्रतिद्वंद्वियों से आगे था। आज का OS और UI आधार 100% बदल चुका है, लेकिन वह priority अब भी बनी हुई है
    • यह इतना खराब है, यह देखकर हैरानी होती है। खासकर Linux में तो और भी। क्या mouse movement को स्वाभाविक रूप से हर दूसरी चीज़ से ऊपर priority नहीं मिलनी चाहिए? mouse जिस object पर hover कर रहा है, उसका highlight होना भी mouse cursor को धीमा नहीं बनाना चाहिए
      हाल ही में KDE/Plasma 6 के X11 और NVidia combination में अत्यधिक mouse slowdown का अनुभव हुआ। खासकर browser tabs के ऊपर slowdown बहुत ज्यादा था, यह नोटिस किया
      जिन लोगों को यही समस्या है, उनके लिए लिख रहा हूं: समाधान OpenGL flipping को बंद करना था। OpenGL flipping क्या करता है, यह मुझे बिल्कुल नहीं पता, लेकिन nvidia-settings और /etc/X11/xorg.conf में इसे बंद करने पर समस्या ठीक हो गई
      कोई समझा दे कि ऐसा क्यों है, या यह default क्यों नहीं है, तो अच्छा होगा

  • शानदार काम है। monitor को बहुत कम refresh rate, जैसे 30Hz, पर रखकर experiment दोहराने लायक हो सकता है
    अगर Wayland हमेशा X11 से एक frame धीमा है, तो उसे observe करना कहीं आसान होगा

  • एक थोड़ा अलग व्यक्तिगत शिकायत है। जब मैंने पहली बार Linux इस्तेमाल करना शुरू किया, तब desktop software compositing पर था। शायद CPU RAM में UI draw करता था और फिर उसे GPU framebuffer में blit करता था; मुझे लगता है यह तरीका काफी पहले से चलता आ रहा था
    compositor, X11 composite सहित, और GPU renderer के चलन में आने के बाद latency भयानक हो गई और सचमुच सैकड़ों ms के स्तर तक पहुंच गई। DOS games खेलते हुए बड़ा हुआ था, तब ऐसी समस्या नहीं थी, इसलिए यह अजीब लगा
    समय के साथ सुधार तो हुआ है, लेकिन मुझे नहीं पता कि हम CPU rendering के स्वर्ण युग में लौट आए हैं या नहीं