X11 - Yönlendirme ve verimlilik

X11 üzerinden iletilmesi gereken grafik olarak yoğun bir uygulamam var. X11 ve verimliliğini araştırmak için biraz zaman harcadım, bu harika yazı da dahil: X11 iletme neden bu kadar verimsiz? .

Benim için hala net olmayan bir şey, X11 iletme performansının uygulamaya bağlı olup olmadığıdır. Ne olursa olsun tüm ekranın yönlendirildiği izlenimindeydim. O zaman X11 iletimi uygulamaya bağlı olmamalıdır.

Peki, gerçekte neyin yönlendirildiği ve ssh -X'in performansının uygulamaya bağlı olup olmadığı konusunda somut bir bilgi var mı?

xorg remote-access x11-forwarding

— zehirli diş
kaynak

"Peki, gerçekte neyin yönlendirildiği ve ssh -X'in performansının uygulamaya bağlı olup olmadığı konusunda somut bir bilgi var mı?" Evet. Başlangıç olarak, Daniel Stone'un LinuxConf.au 2013'ten Wayland ve X'in Gerçek Hikayesi başlıklı konuşmasına bakın.

— sampablokuper

"Tüm ekranın yönlendirildiği izlenimindeydim." Size bu izlenimi verecek olan şeyi anlamak zor, çünkü insanların genellikle SSH X iletimi ile yaptıkları uzak kabuk üzerinde tek tek uygulamaları manuel olarak çalıştırmaktır; uygulamaları nasıl başlattığınız hakkında biraz ayrıntı verebilir misiniz?

— rakslice

X oturumunu bir SSH tüneli üzerinden taşıyorsanız dikkat etmeniz gereken bir faktör: ssh sıkıştırma yapabilir. Bu var -Ckomut satırından veya opsiyon Compression: yes.ssh / config dosyasındaki seçeneği. Sıkışık bir T1 bağlantısı üzerinden Dallas'tan Avustralya'ya geleneksel X iletimi yapıyorsanız, bu, arayüzünüzde beş düzey derinlikte bir iletişim kutusu oluşturma ve gerçekçi olmayan bir görevden sadece aşırı derecede bir onay kutusu seçme göreviniz arasındaki fark olabilir. iki saat sinir bozucu. Neyse ki Wayland ile denemek için gerek yoktu, ama büyük ölçüde geliştirilmiş olduğunu varsayıyorum.

— Ed Grimm

Özellikle sorularım @grawity tarafından çok iyi yanıtlandığından, yorumlarda kapsamlı bir tartışma başlatmak istemiyorum. "Tüm ekran" derken, ssh tüneli üzerinden iletilen verilerin her zaman ekrandaki piksellerin basit bir açıklaması olacağını kastediyorum. @ EdGrimm: Sıkıştırma hakkındaki yorumunuz için teşekkür ederim. Bunun farkındayım. Bizim özel senaryomuzda, X11 10Gbit LAN Link üzerinden iletilir ve sıkıştırma / sıkıştırma hiçbir fark yaratmaz.

— Fang

Ne olursa olsun tüm ekranın yönlendirildiği izlenimindeydim. O zaman X11 iletimi uygulamaya bağlı olmamalıdır.

Hayır, aslında tam tersi. X11 iletiminin "X11 iletim" olarak adlandırılmasının nedeni , uygulamalarını pencerelerini "X sunucusunda" (genellikle Xorg) oluşturmak için kullanılan gerçek X protokol mesajlarını taşımasıdır . Bu mesajlar, pencere oluşturma / taşıma, metin çizme ve grafik temel öğeleri (çizgiler / dikdörtgenler), çizim bitmap'leri vb. İçin komutlardır.

Kavramsal olarak VNC / RFB gibi "tam ekran görüntü" protokollerinin tersi olduğunu söyleyebilirsiniz . Bence GDI çizim komutlarını taşımak için yapılmış olan Windows RDP ile biraz karşılaştırılabilir.

Yani programlar arasındaki farkları görmenizin nedenleri:

Referans verdiğiniz yayını alıntılamak için başlangıçta X tabanlı programların çoğu şu şekilde çalıştı:

Temel olarak X11 ekranı bilgisayarınıza göndermez, ancak yerel bilgisayarınızdaki X sunucusunun ekranı yerel sisteminizde yeniden oluşturabilmesi için görüntüleme talimatlarını gönderir.

Bir program bir düğme göstermek istediğinde, sadece birkaç kısa komut gönderdi - "dikdörtgen çiz", "metin çiz" ve belki de 3 boyutlu görünmesi için bazı satırlar.
Zamanla bu değişti, programlar kendi başlarına render yapmaya başladı ve bu talimatların çoğu sadece "işte bitirdiğim, bunu ekrana koyduğum bir bitmap" haline geldi - yerel olarak çok hızlı, ancak X11'in herhangi biri eksik olduğu için ağ üzerinde çok yavaş görüntü sıkıştırma.

Bu, modern araç kitleri kullanılarak oluşturulan programların, kenarları yumuşatılmış yazı tipleri kadar basit olsa bile, ağa bağlı X11'e göre çok daha yavaş olduğu anlamına gelir.

(Buna karşılık, RDP zaman içinde adapte olmuştur ve JPEG ve hatta H.264 gibi çeşitli görüntü sıkıştırma biçimlerini içerir; tam görüntü yüklenirken sık sık sıkıştırma yapaylıklarını fark edebilirsiniz.)
Neyse ki, GTK gibi çoğu UI araç kiti hasar izlemeyi uygular, böylece sadece güncellenen bölgeler tekrar gönderilir. Ancak, birkaç program (birkaç Firefox / Thunderbird sürümü gibi) bunu desteklemez ve gerçekten güncellenmemiş olsa bile tüm pencerenin tamamen yeniden oluşturulmasını ister.

Bu programlar arasındaki başka bir fark - iyi davrananlar hala ağ üzerinden oldukça kullanılabilir, ancak buggy olanlar 100 Mbps bağlantıyı kesinlikle yararlı bir şey yapmadan doyurabilir.

— user1686
kaynak

Bir keresinde bir MythTV sunucusu kurmaya çalıştığımı hatırlıyorum. "Kurulum" yardımcı programı bir Qt uygulamasıydı ve darboğaz olarak makul bir ADSL bağlantısına (yaklaşık 8 Mb / s) rağmen her yapılandırma sayfasını görüntülemek birkaç dakika sürdü. Bu nedenle birkaç dakikalık bir çalışma birkaç saat sürdü - bir Curses kullanıcı arayüzü veya hatta iyi bir X11 uygulaması ile çok daha kolay olurdu. Ne kadar sorun olacağını biliyor olsaydım, yerinde olana ve disksiz ön uç kutularından birini görüntülemek için kullanılana kadar bir iki hafta beklerdim. Sunucunun çalışmasını ve daha önce çalışmasını istedim.

— Toby Speight

Bu "buggy programlarının" savunulmasında, bunun X + araç kiti ideolojisinin hatası olduğu ve temelde bu buggy programlarının ilk başta buggy olmasını gerektirdiği belirtilmelidir. Bir programın "normal görünümlü bir pencere", bir menü ve bir düğme ve burada bir kaydırma çubuğuna sahip olması için bir API (komut gönderir) arayabileceğini düşünürdünüz, ancak hayır. Siz veya araç seti, her şeyi el ile yapmanız gerekir. Gerçekten hiçbir büyük MS'in Fan ve daha az Apple böylece değilim, ama var böyle şeyler X ekosistem yıllardır emdi ve hala berbat etmiştir sağ oysa.

— Damon

Yine de bir fark olup olmadığından emin değilim. Windows'un UWP veya WinForms veya comctl32'sini GTK ve QT'den daha az bir "araç takımı" yapan nedir? Her şeyi "elle" de yapmıyorlar mı?

— user1686