Wayland ve X11 giriş gecikmesi tartışması için somut sayılar

• Fedora Workstation 41 ve GNOME 47 ortamında imleç giriş gecikmesi, 240 FPS ağır çekimle kaydedilerek Wayland ve X11 karşılaştırıldı
• Fare hareket etmeye başladığı kareden imlecin yeni konumda göründüğü kareye kadar sayılarak, Wayland için 16 ve X11 için 16 kare gecikmesi kaydedildi
• GNOME X11 ortalama 4 kare, 16,7 ms ve 2,4 ekran yenilemesi; GNOME Wayland ise ortalama 5,5625 kare, 23,2 ms ve 3,3 ekran yenilemesi olarak ölçüldü
• Bu sistemde Wayland, X11’e kıyasla ortalama yaklaşık 6,5 ms daha yüksek imleç gecikmesi gösterdi; fark neredeyse 1 ekran yenilemesine yakındı
• Sonuçlar yalnızca GNOME/AMD kombinasyonundaki imleç gecikmesi farkını gösteriyor; oyunlarda veya genel grafik uygulamalarında Wayland giriş gecikmesinin daha yüksek olduğuna kanıt değildir

---

Neden ölçüldü?

• Bir Linux kullanıcısı, Wayland giriş gecikmesi şikâyetlerini ele alan Wayland Cursor Lag: Just give me a break already... yazısından hareketle, öznel hissiyat yerine somut sayılar elde etmek için bir deney yaptı
• Wayland’i genel olarak memnuniyetle kullanmasına rağmen, X11’e göre daha fazla imleç gecikmesi olduğu izlenimi deneyin çıkış noktasıydı
• Önceki yazıdaki 90 FPS telefon kamerasının, bir ekran yenilemesi düzeyindeki farkı değerlendirmek için yeterli olmadığı düşünülerek 240 FPS çekim modu kullanıldı

Ölçüm yöntemi

• Telefon kamerasıyla ekran, masa, fare imleci, fare ve el birlikte kadraja alınırken fare parmakla tekrar tekrar hafifçe itildi
• GNOME Wayland oturumunda 16 çekim yapıldıktan sonra GNOME X11 oturumunda oturum açılıp aynı yöntemle 16 çekim daha yapıldı
• Çekilen videolar ffmpeg -i <input file> %04d.jpg komutuyla JPEG karelerine dönüştürüldü
• Kare gecikmesi şu ölçütlerle sayıldı
  • Farenin hareket ettiğinin görüldüğü ilk kareden saymaya başlandı
  • İmlecin yeni konumunda açıkça hareket ettiğinin görüldüğü ilk kareye kadar sayıldı
  • Başlangıç ve bitiş kareleri de sayıya dahil edildi
  • Örneğin fare 1045. karede hareket ediyor ve imleç 1047. karede hareket ediyorsa, bu 3 kare gecikme olarak kaydedildi

Test ortamı

• Deneyde kullanılan donanım ve yazılım şöyleydi
  • Dağıtım: Fedora Workstation 41
  • GNOME sürümü: 47
  • CPU: AMD Ryzen 9 5950X
  • GPU: AMD Radeon RX 7900XT
  • Monitör: Gigabyte M32U, 4K IPS, 144,99 Hz, DPI ölçekleme yok
  • Fare: Logitech G502 Lightspeed
  • Kamera: iPhone 15 Pro, 240 FPS ağır çekim

Ölçüm kısıtları

• 240 FPS bile 144 Hz ekranda ekran yenilemesi başına 2’den az kamera karesi sunduğu için rastgele değişkenlik oluşur
• Pikseller anında geçiş yapmadığından, imlecin yeni konumda çok silik görünmeye başladığı muğlak kareler vardır
• İmleç tamamen parlaklaşmamış olsa bile yeni konumda açıkça görülebiliyorsa imlecin hareket ettiği kabul edildi
• iPhone videosunda bazı yinelenen kareler vardı; nedeni bilinmiyor
  • Yinelenen kareler, bir karelik sürenin geçtiği varsayılarak normal kareler gibi sayıldı
• Bu etkenler sonuçlarda belirsizlik yaratsa da Wayland ve X11’i aynı şekilde etkileyecekleri ve yeterli veri olduğunda ortalamada dengelenecekleri varsayıldı
• GNOME dışındaki Wayland compositor’ları ve AMD dışı GPU sürücüleri test edilmediğinden, diğer kombinasyonlarda sonuçlar farklı olabilir

Ölçüm sonuçları

• GNOME X11 için 16 ölçüm değeri 5, 4, 3, 4, 5, 4, 6, 5, 1, 4, 4, 4, 3, 4, 4, 4 kareydi
  • Ortalama: 4 kare
  • Gecikme süresi: 16,7 ms
  • Ekran yenilemesi: 2,4 kez
• GNOME Wayland için 16 ölçüm değeri 6, 5, 6, 5, 5, 6, 6, 4, 8, 6, 5, 5, 5, 6, 5, 6 kareydi
  • Ortalama: 5,5625 kare
  • Gecikme süresi: 23,2 ms
  • Ekran yenilemesi: 3,3 kez
• Bu sistemde Wayland, X11’e kıyasla ortalama yaklaşık 6,5 ms daha yüksek imleç gecikmesi gösterdi
• Bunun istatistiksel olarak anlamlı olup olmadığını düzgün analiz edecek uzmanlık yok, ancak ölçüm değerlerine bakıldığında belirgin ve tutarlı bir fark var gibi görünüyor
• Fark neredeyse 1 ekran yenilemesine yakın; bunun tesadüf olup olmadığı bilinmiyor

Sonuç ve yorum kapsamı

• Bu deney, belirli bir donanımda X11 ile Wayland arasında giriş gecikmesi farkı olduğunu ve bunun bazı kullanıcıların fark edebileceği kadar büyük olabileceğini gösteriyor
• Sorunun kapsamını ve büyüklüğünü netleştirmek için daha çeşitli donanımlar ve ekran yenileme hızlarında ek testler gerekiyor
• Farkın büyüklüğü, kullanılan compositor ve ekran yenileme hızı gibi etkenlere bağlı olarak değişebilir
• Ek deneyler çok zaman alacağından, bunların bizzat yapılmama olasılığı yüksek
• Bu test, Wayland’in genel olarak X11’den daha yüksek giriş gecikmesine sahip olduğunu göstermiyor
  • Özellikle oyunlarda Wayland giriş gecikmesinin daha yüksek olduğuna kanıt değildir
  • Ek gecikmenin yalnızca imlece özgü olma ihtimali var
  • İmlecin genel grafik uygulamalarından çok farklı şekilde işlendiği anlaşılıyor
  • Wayland’in oyunlarda X11’e göre daha yüksek giriş gecikmesi gösterip göstermediği ayrı test gerektirir

[GN⁺]

Hacker News yorumları

• Harika bir yaklaşım. İnsanlar deneysel olarak doğrulayabilecekleri şeyleri fazla sık tahminle geçiştiriyor gibi. Bilimsel yöntemi öğrendiğimden beri hep “bir deney tasarlayalım” tarafına çekildim.
  Wayland’de neden ek gecikme oluştuğunu bilmiyorum ama X11’in ilk çıktığı dönemlerde bilgisayar topluluğunun içinde olan biri olarak, en başından beri ekran gecikmesiyle ilgili şikâyetlerin hiç eksik olmadığını söyleyebilirim. İster imleç tepkisi olsun ister xterm kaydırması, durum aynıydı.
  “İş istasyonları” ortaya çıktığında bazılarında yalnızca fare için ayrı görüntü donanımı bulunuyordu; bu, fareyi kare içinde render etme gecikmesini azaltmaya yönelik bir düzenekti. Meşhur XOR patenti de vardı: https://patents.google.com/patent/US4197590
  Bu şikâyetler sayesinde klavye/fare girdisinden ekrana yansımaya uzanan kod yolu sürekli “daha hızlı, daha düşük gecikmeli” hâle getirmenin yolları açısından incelendi. Wayland, X11’e kıyasla görece “yeni” olduğu için aynı ölçüde uzun süre sınanmadı; ama insanların bunu düzelteceğini umuyorum.

  • Görüntü aygıtlarında, genellikle GPU’nun bir kısmında, hâlâ yalnızca fareye yönelik açık görüntü donanımı var; bugün bu imleç düzlemi (cursor plane) biçiminde bulunuyor. Daha sonra bunun daha genelleştirilmiş hâli olan overlay düzlemleri de ortaya çıktı.
    Düzlemler, ekranın geri kalanı yeniden çizilmeden güncellenebilir veya konumları değiştirilebilir. Normal ekran görüntüsü birincil düzlemdedir; imlecin hareketi ise yeni düzlem konumunu commit etmeye daha yakındır.
    Burada kullanılan Wayland sunucusu GNOME Mutter’ın eklediği giriş gecikmesi muhtemelen giriş örnekleme ve commit zamanlaması stratejisiyle ilgili bir sorundur. Sunucuların stratejileri ve öncelikleri farklı olduğundan artı ve eksiler ortaya çıkar.
    Wayland bir protokol olduğundan genel imleç konumlandırma sürecine karışmaz. Dolayısıyla bu sorun tamamen görüntü sunucusunun iç uygulaması ve optimizasyon alanındadır. Protokol düzeyinde olan şeyler, istemcinin imleç görüntüsünü ayarlamasına izin vermek ve istemciye imleç konumunu bildirmekle sınırlıdır.
  • Eskiden XFree86 ve Xorg, SIGIO işleyicisi içinde işaretçiyi doğrudan güncellerdi. Ama bu artık çok eski bir hikâye; bugün bu alanda Wayland ile Xorg’un çok farklı olmasını beklemem.
    Hatırladığım kadarıyla Xorg’da glamour ortaya çıktığında işler kötüleşmeye başladı. İmleç render yolu sinyal işleyicisi içinde çalıştırılmaya güvenli olmaktan çıkınca —OpenGL tabanlıysa elbette böyle olması kaçınılmazdı— gecikme daha da kötüleşti.
    Eskiden bir Linux makinesi thrashing içindeyken bile fare işaretçisi tepki vermeye devam ederdi; çekirdeğin donup donmadığını anlamak için güvenilir bir göstergedir. İşaretçi yeterince erken tepki vermiyorsa, IDE/PATA host’unda hdparm ile unmask irq’yu açmanız gereken durumlardan biriydi. XFree86’da tepki vermeyen işaretçi, bir şeylerin yanlış olduğuna veya yapılandırmanın hatalı olduğuna dair çok yararlı bir işaretti; o günleri özlüyorum.
  • Wayland kaç yaşında? Bu hızla mezarda “bahar rüyası” okuyor oluruz.
    Bedava yazılımdan şikâyet ettiğimin farkındayım ama bu, çok uzun süredir daha kötü olana zorunlu geçiş hâlinde. Wayland’in benimsenmesi, tüm giriş ve görüntü gereksinimlerinde neredeyse evrensel olarak üstün olduğu varsayımı üzerine gerçekleşmeliydi.
    Intel, AMD, Nvidia, Arm üreticileri kullanılabilir bir masaüstü Linux için konsorsiyum olarak tüm güçlerini ortaya koymalı. Hükümetler de öyle. Çünkü güvenli bir Linux masaüstü gerçekten mümkün ve CPU ile 3D yeteneklerini, gelişmiş vektör/bilgisayar donanımını göstermenin en hızlı yolu bu.
    Wayland, Windows’un korkunç döşeme arayüzüyle kendini mahvetmeye çalıştığı, Apple’ın genel x86 için macOS çıkarsaydı elde edebileceği ek piyasa değerini inatla reddettiği bir dönemde ortaya çıkıp Linux masaüstü gecikmesini daha da artırmış oldu.
  • “Yalnızca fareye yönelik açık görüntü donanımı vardı ve gecikmeyi azaltıyordu” meselesi bugün de geçerli. Fare imleci, pencere compositor’ünün swapchain’inden bağımsız bir sprite/overlay olarak render edilir. Aksi hâlde özellikle 60Hz’de gecikme çok belirgin olur.
    İncelik gerektiren kısım bir pencereyi veya simgeyi sürüklerken ortaya çıkar; o zaman swapchain gecikmesi görünmeye başlar. Bazı pencere compositor’leri yüksek yenileme hızı sayesinde gecikmenin daha az görünür olduğunu düşünüp artık umursamıyor; örneğin macOS böyle, Windows ise sürükleme sırasında yazılımsal fare imlecine geçiyor gibi.
  • GNOME’da unredirection desteği var; bu yüzden bu testin gerçek oyun performansına uygulanabileceğini söylemek zor.
    Tam ekran uygulamalar compositor’den geçen ya da onu bypass eden hızlı bir yol kullanmalı.

• Bu tür kare düzeyi analiz için ffmpeg kullanan biriyseniz, videodaki her karenin gösterim zamanını ffmpeg -skip_frame nokey -i file -vsync 0 -frame_pts true out%d.png ile alabilirsiniz. Bu, kareleri doğrudan döküp zaman damgalarını hesaplamaktan daha doğrudur.
  Web tarayıcısında da videoyu oynatırken requestVideoFrameCallback() kullanarak benzerini yapabilirsiniz. Ancak bilgisayar tüm kareleri yeterince hızlı decode edemiyorsa .playbackRate değerini düşürmeniz gerekebilir.
  144Hz ekranda Wayland’in X11’den ortalama yaklaşık 6,5 ms daha yavaş olması ve bu farkın neredeyse tek bir ekran yenilemesine eşit olması tesadüf olmayabilir. Gecikme neredeyse 1/144 saniyeyse, sıradan 60Hz monitörde 1/60 saniye olabilir. Eğitim olmadan bilinçli olarak fark etmek zordur ama çoğu kişi açıklayamasa da bunu “hissedebilir”.

  • Tahminimce “gerçek” değerler 2,5 kare ve 3,5 kareye daha yakın. Fareye dokunulan an ile ekran yenilemesi arasındaki rastgele faz yüzünden ortalama yarım kare, bunun üzerine imleç hareketi için 2 kare veya 3 kare eklenmesi gibi. Her kümedeki düşük aykırı değerleri çıkarırsanız bu değerlere oldukça yaklaşıyor.
    Elbette birçok kullanıcı için 125Hz fare polling oranı da karıştırıcı bir etken olurdu, ancak bu durumda 1KHz fare kullanılmış.
    7 ms fark fena değil, ama 16,6 ms fark epey büyümeye başlar. Kişisel olarak bilgisayarların 1,6 kare gecikmeyi hedeflemeye çalışması gerektiğini düşünüyorum. Rastgele fazdan yarım kare, bir kare ve biraz işlem süresi kadar.
  • Düşük gecikmeli terminaller, basit yazı yazma gibi işlerde bile hissedilir bir iyileşme sağlar.
  • Fare hareketi ile ekran arasına bir karelik tamponlama eklenmiş gibi görünüyor. Dikey senkronizasyon buna yol açabilir, ama yalnızca çift tamponlamayla da dikey senkronizasyon mümkün olmalı.

• Sonuçlar birleştiriciye, GPU’ya ve ayarlara göre değişecektir. X11’de Linux masaüstü sistemlerinin kullandığı X sunucusu uygulaması fiilen tek olduğu için bu tür farklar daha azdır.
  Hâlâ birçok birleştirici/GPU kombinasyonunda donanım imleç düzlemi elde edilememe sorunu olabilir; öyleyse bu tür gecikme farkları rahatlıkla ortaya çıkabilir.

• Bugün öğrendim ki Wayland şimdiden 16 yaşındaymış. Birkaç yıl sonra Wayland, çıktığı zamanki X’in yaşıyla aynı yaşa gelecek; ama hâlâ sıradan ya da X’ten kötü görülüyor gibi.

  • X’in ilk sürümü Haziran 1984’te, Wayland ise ilk kez 2008’de çıktı; dolayısıyla Wayland’in aynı yaşa gelmesi için 2032’yi bulması gerekir. İnsanlar Wayland’in sıradan olduğundan ya da “X kadar iyi olmadığından” şikâyet ettiğinde çoğu zaman kastettikleri şey “Wayland $very_specific_feature desteklemiyor” ya da “ekran kartı üreticimin kapalı kaynak sürücüsü Wayland’de yeterince test edilmediği için üzgünüm” oluyor.
    Bu şikâyetlerin yaklaşık %99,999’u 1) işi kendileri yapmayan, 2) işi yapmaya ilgisi ya da yetkinliği olmayan ve 3) Wayland ile X geliştiricilerinin çoğunlukla aynı kişiler olduğunu ve artık X11 üzerinde çalışmak istemediklerini anlamayan ya da kabul etmeyen kişilerden geliyor.
    Bu tartışmada özel bir çıkarım yok, ama başkalarının ücretsiz verdiği yazılımı kullanırken insanların Wayland’den şikâyet etmesini görmekten yoruldum. Wayland şikâyetleri bu kadar çoksa, şimdiye kadar bir araya gelip X’i bakımda tutup geliştirebilirlerdi; şikâyetleri ve teorileri doğruysa Wayland’i geride de bırakabilirlerdi.
    Garip olan şu ki X açık kaynaklı ve istenildiği kadar çatallanabilir; XFree86’dan X.org’un çıkmış olması gibi bir örnek varken bile destekçileri onu tozlanmaya bırakıyor ve bakım için hiçbir şey yapmıyor.
    “Wayland X kadar iyi değil, bu yüzden herkesin kullanabileceği modernleştirilmiş bir X çatallaması yaptık” gibi bir sonuç ortaya çıkarsa oldukça ilgiyle bakarım.
  • Hayır, öyle değil. X 1984 çıkışlı: https://www.talisman.org/x-debut.shtml
    Yani Wayland, Wayland çıktığı zamanki X’in yaşının yalnızca yaklaşık %66’sında; aynı yaşa gelmesi için Wayland’in bugünkü ömrüne %50 daha eklenmesi gerekiyor.
  • X 40 yaşında, Wayland 16 yaşındaysa fark 24 yıl. Dolayısıyla Wayland birleştiricilerinin sorunları cilalamak için 8 yılı kalmış demektir.
    Şu anda Plasma 6’da Wayland kullanıyorum ve yeterince iyi çalışıyor; ancak özel gereksinimlerim yok, bu yüzden örneğin ekran okuyucuların ne kadar iyi çalıştığını bilmiyorum.
  • Bu sayılara başka bir açıdan bakarsak, birkaç yıl sonra Wayland’in halefinin çıkma zamanının geldiği anlamına da geliyor. Wayland ile aynı motivasyonla, yani eski yazılımı bakımda tutmak isteyen kişi eksikliği yüzünden çıkabilir.
    O noktada tarayıcı frontend yığınının masaüstünü tamamen yutacağını tahmin ediyorum. Zaten Linux’a çok sayıda yeni masaüstü uygulaması da gelmiyordu.
  • Wayland, Windows Vista’nın birleştiricisiyle aynı dönemde çıktı. Cömert davranıp bir sonraki sürüm olan Windows 7’de “iyi ve kararlı” bir birleştiriciye kavuşulduğunu varsaysak bile Wayland, Windows’un 13 yıl gerisinde kalıyor.

• Çalışan bir çözümü “daha modern, bakımı daha kolay ve geleceğe hazır” diye yeniden yazma girişimlerinin çoğunun böyle sonuçlanmaması şaşırtıcı değil. Genellikle daha yavaşlıyor, gecikme artıyor; yalnızca daha hızlı donanım bunu sırtlıyor, yazılımın hızlandığı yok.
  Her 20 yılda bir yeni neslin, önceki neslin zor işi yaparak kurduğu soyutlamalara şımarıkça yaslanıp daha da zayıfladığı hissine kapılıyorum. Yazılım geliştiricilerinin üç nesli kadar geçtikten sonra geriye yalnızca kütüphane/framework çağıranlar kalmış gibi; performans ve optimizasyonu doğru düzgün bilen çok az kişi var.

  • Benim deneyimim farklı. Birkaç bilgisayarı KDE 6’ya yükseltip Wayland’e geçirdiğimde sistemin genel tepki verme hızı ve akıcılığı belirgin biçimde iyileşti.
    Wayland’in X11’e kıyasla hâlâ eksik özellikleri var, ama diğer avantajları nedeniyle bu kadarını kabul etmeye hazırım.
  • Eski bilgisayarlarda gecikme daha düşüktü; ama buna karşılık birçok işletim sisteminde tek bir uygulama çöktüğünde tüm işletim sistemi yanıt vermez hâle gelir ve bütün sistemi yeniden başlatmak gerekirdi.

• Birçok Wayland birleştiricisinde klavye, fare ve diğer giriş aygıtları konusunda büyük sorunlar var. Çünkü Wayland spesifikasyonu ve referans uygulaması bunları desteklememeyi seçti. Bu yüzden her Wayland birleştiricisi farklı bir çözüm seçiyor.
  Yaygın seçenekler libei ve libinput, ancak “gelişmiş” fare/klavye girişi çoğu zaman hiç desteklenmiyor. weston bunun bir örneği. Belirli bir Linux yazılımının belirli bir Wayland ortamında çalışıp çalışmayacağını hiç bilemiyorsunuz ve parçalanma ciddi.
  X’te ise pratikte her şeyi uygulayan güçlü bir X11 referansı var; bir yerde çalışıyorsa başka yerde de çalışacağından emin olabiliyorsunuz.
  Üstelik 12 yıl geçmesine rağmen görme engelliler için ekran okuyucuları destekleyen tek bir Wayland birleştiricisi bile yok. Oyuncak seviyesinde.

  • Renk kalibrasyonu desteğinin de eksik olduğunu duydum. Okuduğum kadarıyla kalibrasyon uygulamasının ölçüm yaparken hangi düzeltmenin uygulandığını kontrol etmesinin ya da bilmesinin bile bir yolu yok gibi. Üstelik istemci tarafı pencere süslemeleri de hâlâ duruyor; böylece eski bir güvenlik açığını düzeltme fırsatından vazgeçilmiş.
    Bu yüzden oyunlar için de iyi değil, profesyonel grafik işleri için de iyi değil, görme yetisi zayıf kişiler için de iyi değil. Sonuçta, onu yapanlardan azıcık farklı kullanıcılara genel olarak iyi gelmiyor demek.
    Yine de şanslıysak benim hiç hissetmediğim ekran yırtılmasını azaltmış olabilir.
  • macOS’tan Windows’a geçtikten sonra sonunda Windows’ta karar kıldım ve boş zamanımdaki geliştirme çalışmalarımı Windows’ta döşemeli pencere yöneticisi ekosistemiyle power user/geliştirici deneyimini iyileştirmeye ayırmaya başladım: https://github.com/LGUG2Z/awesome-komorebi
    Buradan çıkan güzel sonuçlardan biri de insanların bu ekosistemin üstüne erişilebilirlik iş akışları eklemesi. Bir kişi sesli kontrolle döşemeli pencere yöneticisi üzerinden tüm masaüstünü yönetiyor: https://youtu.be/fiPJLmhnnXM
  • “Gelişmiş fare/klavye girişini hiç desteklemiyor” demek muhtemelen yanlış tarafı suçlamak oluyor. Böyle çevre birimleri üretip Linux sürücüsü sağlamayan şirketlere bakmak gerek.
  • GNOME’un Wayland oturumunda Orca kullanırken ne eksik kalıyor?

• GPU ağır yük altındayken, örneğin Stable Diffusion çıkarımı gibi işler yaparken büyük gecikme sıçramaları oluşuyor. X11 ile A/B testi yapmış değilim ama eskiden böyle bir şey hatırlamıyorum
  Tek bir kare kadar ek gecikme olması da hoş değil, ama ara sıra fırlayan gecikme sıçramaları gerçekten sinir bozucu

  • Özellikle VRAM ile sistem belleği arasında thrashing yaşanan durumlarda hâlâ ortaya çıkabilir. Yine de Stable Diffusion sürecinin önceliğini düşürmeyi denedin mi merak ediyorum

• İmleç giriş gecikmesi, bir uygulamadan ya da işletim sisteminden alınan memnuniyeti sürekli kemiren bir engel
  IDE metin imleci gecikmesi? Kabul edilemez
  Shell metin imleci gecikmesi? Kabul edilemez
  GUI fare imleci gecikmesi? Kabul edilemez
  Bunların hepsi anında eleme sebebi

  • macOS’un her zaman mükemmel olduğu alanlardan biri; klasik Mac OS dönemine kadar uzanıyor
    40 yılı aşkın süre önce, neredeyse sonsuz derecede zayıf donanımlarda çalışan System 1 bile imleç tepkiselliğini en üst öncelik yaparak tüm rakiplerini geride bırakmıştı. Bugünün OS ve UI temelleri %100 farklı olsa da bu öncelik hâlâ korunuyor
  • Bunun bu kadar kötü olması şaşırtıcı. Özellikle de Linux söz konusuysa. Fare hareketi doğal olarak her şeyden önce gelmemeli mi? Farenin üzerinde olduğu öğenin vurgulanması bile fare imlecinin kendisini yavaşlatmamalı
    Yakın zamanda KDE/Plasma 6’nın X11 ve NVidia kombinasyonunda aşırı fare yavaşlaması yaşadım. Özellikle tarayıcı sekmelerinin üzerinde yavaşlamanın belirgin olduğunu fark ettim
    Aynı sorunu yaşayanlar için not düşeyim: Çözüm OpenGL flipping’i kapatmaktı. OpenGL flipping’in ne yaptığını hiç bilmiyorum ama nvidia-settings ve /etc/X11/xorg.conf üzerinden kapatınca sorun çözüldü
    Birisi bunun nedenini ya da bunun neden varsayılan olmadığını açıklarsa iyi olur

• Güzel çalışma. Monitörü çok düşük bir yenileme hızına, örneğin 30Hz’e ayarlayıp deneyi tekrarlamaya değer gibi
  Wayland her zaman X11’den bir kare daha yavaşsa, bunu gözlemlemek çok daha kolay olur

• Biraz farklı kişisel bir şikâyetim var. Linux kullanmaya ilk başladığımda masaüstü yazılım tabanlı compositing kullanıyordu. Muhtemelen CPU arayüzü RAM’e çiziyor, ardından GPU framebuffer’ına blit ediyordu; bunun uzun zamandır böyle yapıldığını düşünüyorum
  Compositor’lar, X11 composite dahil, ve GPU renderer’lar popülerleşince gecikme korkunç hâle geldi ve kelimenin tam anlamıyla yüzlerce ms seviyesine çıktı. DOS oyunlarıyla büyürken böyle bir sorun yoktu, bu yüzden tuhaf gelmişti
  Zamanla iyileşti ama CPU rendering’in altın çağına geri dönüp dönmediğimizden pek emin değilim