Dlaczego przekazywanie X11 jest tak nieefektywne?

Ilekroć uruchamiam zdalnie duże GUI z przekazywaniem X11, nawet włączając przełącznik -C, wrażenia nie reagują. Moje pytanie brzmi: co to powoduje na poziomie koncepcji / protokołu?

Dzięki mojemu 25mbitowemu połączeniu mogę bez problemu przesyłać strumieniowo wideo HD do mojego komputera. Z drugiej strony brak reakcji na zdalnie uruchamiane GUI z przekazywaniem X11 zdarza się nawet w 100-bitowej sieci LAN, gdzie opóźnienie powinno być bliskie zeru.

Rozumiem, że w przeciwieństwie do przesyłania strumieniowego wideo opóźnienie będzie w najlepszym razie podwojone (ponieważ dane wejściowe muszą zostać przesłane do zdalnego komputera, a dopiero potem aplikacja może odpowiedzieć), ale wewnętrznie istnieją inne czynniki, które zwiększają opóźnienie nawet dalej?

Po drugie, przepustowość. Dlaczego tak dużo tego zjada? Jeśli chodzi o formaty zdjęć i filmów, stosuje się wiele metod drastycznego zmniejszenia rozmiaru.

Na przykład w przypadku .bmp vs .png duży czarny kwadrat będzie reprezentował znacznie mniej reprezentacji .png, ponieważ informacje nie są przechowywane dla każdego pojedynczego piksela, ale w zakresie, w jakim rozumiem.

W przypadku filmów można zapisać wiele informacji, wysyłając różnicę między klatkami, a nie całymi klatkami.

Wiem, że jest to bardzo uproszczone, ale czy X11 nie używa tych metod? Czy na pewnym poziomie zachowuje się w oparciu o mapę bitową lub zasadę nieróżnicową? A jeśli nie, dlaczego zajmuje tak dużo przepustowości?

Protokół X11 nigdy nie miał obsługiwać operacji graficznych (pod względem bitmap / tekstur). W czasach, gdy X11 zostało zaprojektowane, grafika komputerowa była o wiele prostsza niż obecnie.

Zasadniczo X11 nie wysyła ekranu do twojego komputera, ale wysyła instrukcje wyświetlania, dzięki czemu serwer X na twoim komputerze lokalnym może odtworzyć ekran w twoim systemie lokalnym. I należy to zrobić przy każdej zmianie / odświeżeniu wyświetlacza.
Tak więc komputer otrzymuje strumień instrukcji takich jak: „narysuj linię w tym kolorze ze współrzędnych x, y do (xx, yy), narysuj prostokąt W szerokości szerokości, wysokość H pikseli z lewym górnym rogiem w (x, y) itp. „
Lokalny klient tak naprawdę nie wie, co należy zaktualizować, a system zdalny ma bardzo mało informacji na temat tego, czego tak naprawdę potrzebuje klient, więc w zasadzie serwer musi wysłać wiele zbędnych informacji, których klient może potrzebować lub nie.
Jest to bardzo wydajne, jeśli renderowany ekran składa się z ograniczonej liczby prostych kształtów graficznych i potrzebna jest tylko niska częstotliwość odświeżania (bez animacji itp.). Tak było w czasach, gdy X11 został opracowany po raz pierwszy.

Ale współczesne GUI mają wiele uroku i wiele z nich należy przesłać ze zdalnego systemu do klienta w postaci bitmap / tekstur / czcionek, które wymagają dość dużej przepustowości. I wszystkie rodzaje cukierków obejmują animowane efekty wymagające częstych aktualizacji. Wyświetlacze też stają się coraz większe, dwa razy szerszy / wysoki to 4x liczba pikseli.

Oczywiście z biegiem czasu wprowadzono ulepszenia do protokołu X11, aby zoptymalizować to w jak największym stopniu, ale podstawowy projekt podstawowy w zasadzie po prostu nie jest dobrze dostosowany do wymagań ludzi, których obecnie oczekują użytkownicy GUI.

Inne protokoły (takie jak RDP i VNC) są bardziej zaprojektowane, aby pozwolić zdalnemu systemowi wykonać całą ciężką pracę i pozwolić temu systemowi zdecydować, które aktualizacje wysłać do klienta (tak skompresowane mapy bitowe), jak najskuteczniej. Często okazuje się to bardziej wydajne w przypadku nowoczesnych GUI.

Żadna z metod nie jest idealna i nie poradzi sobie równie dobrze z każdą sytuacją. Nie ma czegoś takiego jak pojedynczy protokół wyświetlania, który mógłby poradzić sobie w każdym możliwym przypadku użycia.
W większości przypadków wystarczy wypróbować wszystkie protokoły obsługiwane między lokalnym klientem a serwerem zdalnym i użyć tego, który daje najlepsze wyniki. A w niektórych przypadkach nie ma wyboru i musisz tylko zadowolić się tym, co jest dostępne.

Większość protokołów pozwala na dostrajanie wydajności, ale wiele z tych ustawień dotyczy tylko serwera i nie jest dostępnych dla przeciętnego użytkownika. (A ich prawidłowe skonfigurowanie to trochę tajemnicza sztuka. Wielu administratorów sys-adminów nie będzie chciało z tym zadzierać.)

W większości przypadków najprostszym sposobem na poprawienie wydajności (czasami dość radykalnie) jest przejście na prostsze środowisko komputerowe z mniejszym zainteresowaniem i rezygnację z używania obrazów tła.

Istnieją przede wszystkim dwa powody, dla których połączenia X11 są powolne, a oba z nich poruszono w pytaniu: przepustowość i opóźnienie. Aby zrozumieć, dlaczego aplikacje X11 działają wolno w sieci, omówmy oba z nich.

Pasmo

X11 domyślnie nie kompresuje danych sieciowych przekazywanych między aplikacją a serwerem wyświetlania. Jak już wspomniałeś, możesz użyć opcji -C w SSH, aby włączyć kompresję, a chociaż to pomaga, nie jest zoptymalizowane do kompresji danych graficznych. W porównaniu do formatów takich jak H.264, które mogą uzyskiwać współczynniki kompresji od 100 do 1, kompresja -C będzie mieć szczęście, jeśli uda się osiągnąć kompresję 2 do 1. Lepszym rozwiązaniem jest użycie kodeka zoptymalizowanego pod kątem grafiki lub wideo dla wideo X11, ale musimy uważać, aby nie spowodować zbyt dużej straty, ponieważ komputery stacjonarne zwykle muszą mieć ostrzejsze obrazy niż film, aby użytkownik mógł nadal wyraźnie czytać tekst i dostrzegaj drobne szczegóły.

Czas oczekiwania

X11 ma zwykle duże opóźnienia, ponieważ większość operacji wymaga wielu podróży w obie strony między aplikacją a serwerem wyświetlania. Po uruchomieniu w sieci LAN, gdzie czasy pingów mierzą mniej niż milisekundę, te wielokrotne podróże w obie strony nie są zauważalne, ale przez połączenie internetowe szybko się sumują.

Rozwiązania

Wiele lat temu powstało kilka projektów mających rozwiązać problemy z przepustowością i opóźnieniami związane z protokołem X11. lbx (Low Bandwidth X) i dxpc (Differential X Protocol Compressor). Nie sądzę, aby lbx kiedykolwiek miał dużą przyczepność, ale dxpc stało się technologią bazową stosowaną w produkcie o nazwie NX . NX stosuje zarówno kompresję stratną, aby zmniejszyć wymagania dotyczące przepustowości, jak i algorytm różnicowy oraz buforowanie w celu zmniejszenia liczby przekazywanych informacji w przód iw tył, co powoduje duże opóźnienia. Używam NX dość często i uważam, że wydajność jest prawie tak dobra jak aplikacje lokalne. Jeśli masz na to ochotę, możesz wypróbować NX i sprawdzić, czy to działa. Minusem jest to, że wymaga zainstalowania oprogramowania na obu końcach połączenia, podczas gdy X11 jest zwykle już zainstalowany.