Warum ist die X11-Weiterleitung so ineffizient?

Immer wenn ich große GUIs mit X11-Weiterleitung aus der Ferne starte, auch wenn der -C-Schalter enthalten ist, reagiert die Anwendung nicht mehr. Meine Frage ist, was bewirkt das auf Konzept- / Protokollebene?

Mit meiner 25-Mbit-Verbindung kann ich problemlos HD-Videos auf meinen Computer streamen. Auf der anderen Seite tritt die Unempfindlichkeit von remote gestarteten GUIs mit X11-Weiterleitung sogar über ein 100-MBit-LAN ​​auf, bei dem die Latenz nahe Null liegen sollte.

Ich verstehe, dass im Gegensatz zum Video-Streaming die Latenz bestenfalls verdoppelt wird (da die Eingabe an die Remote-Maschine gesendet werden muss und erst danach die Anwendung reagieren kann), aber intern gibt es andere Faktoren, die die Latenz sogar erhöhen des Weiteren?

Zweitens die Bandbreite. Warum frisst es so viel davon? Bei Bild- und Videoformaten werden viele Methoden verwendet, um die Größe drastisch zu reduzieren.

Im Fall von .bmp vs .png wird zum Beispiel ein großes schwarzes Quadrat in der .png-Darstellung viel weniger benötigt, da die Informationen nicht für jedes einzelne Pixel gespeichert werden, sondern, soweit ich weiß, in einer Entfernung.

Bei Videos können viele Informationen gespeichert werden, indem der Unterschied zwischen Frames und nicht den ganzen Frames gesendet wird.

Ich weiß, dass dies sehr vereinfacht ist, aber verwendet X11 diese Methoden nicht? Verhält es sich auf einer bestimmten Ebene nach einem Bitmap-Prinzip oder nach einem nicht-differentiellen Prinzip? Und wenn nicht, warum nimmt es so viel Bandbreite in Anspruch?

Das X11-Protokoll war niemals dazu gedacht, intensive grafische Operationen (in Bezug auf Bitmaps / Texturen) durchzuführen. Damals, als X11 zum ersten Mal entworfen wurde, war die Computergrafik viel einfacher als heute.

Grundsätzlich sendet X11 den Bildschirm nicht an Ihren Computer, sondern sendet die Anzeigeanweisungen, damit der X-Server auf Ihrem lokalen Computer den Bildschirm auf Ihrem lokalen System neu erstellen kann. Dies muss bei jeder Änderung / Aktualisierung der Anzeige erfolgen.
Ihr Computer erhält also eine Reihe von Anweisungen wie "Zeichnen einer Linie in dieser Farbe von den Koordinaten x, y bis (xx, yy), Zeichnen eines Rechtecks ​​mit einer Breite von W Pixeln, einer Höhe von H Pixeln mit einer oberen linken Ecke bei (x, y) usw.". "
Der lokale Client ist sich nicht wirklich bewusst, was aktualisiert werden muss, und das ferne System hat nur sehr wenige Informationen darüber, was der Client tatsächlich benötigt. Daher muss der Server im Grunde genommen viele redundante Informationen senden, die der Client möglicherweise benötigt oder nicht.
Dies ist sehr effizient, wenn die zu rendernde Anzeige aus einer begrenzten Anzahl einfacher grafischer Formen besteht und nur eine geringe Aktualisierungsfrequenz (keine Animationen und dergleichen) erforderlich ist. Das war damals der Fall, als X11 zum ersten Mal entwickelt wurde.

Moderne GUIs bieten jedoch eine Menge Aufmerksamkeit, und vieles davon muss vom Remote-System in Form von Bitmaps / Texturen / Schriftarten, die eine beträchtliche Bandbreite beanspruchen, an Ihren Client gesendet werden. Und alle Arten von Augenweiden beinhalten animierte Effekte, die häufig aktualisiert werden müssen. Und die Displays werden immer größer, doppelt so breit / hoch wie die vierfache Pixelanzahl.

Natürlich wurden im Laufe der Zeit Verbesserungen am X11-Protokoll vorgenommen, um dies so weit wie möglich zu optimieren, aber das grundlegende zugrunde liegende Design ist im Wesentlichen einfach nicht gut für die Anforderungen der heutigen Benutzeroberflächen geeignet.

Andere Protokolle (wie RDP und VNC) sind eher so konzipiert, dass das Remote-System die harte Arbeit erledigt und entscheidet, welche Aktualisierungen so effizient wie möglich an den Client (als komprimierte Bitmaps) gesendet werden. Oft stellt sich heraus, dass dies für moderne GUIs effizienter ist.

Keine der beiden Methoden ist perfekt und kann mit jeder Situation gleich gut umgehen. Es gibt kein einziges Anzeigeprotokoll, das für jeden denkbaren Anwendungsfall geeignet ist.
In den meisten Fällen probieren Sie einfach alle Protokolle aus, die zwischen Ihrem lokalen Client und dem Remote-Server unterstützt werden, und verwenden Sie das Protokoll, das die besten Ergebnisse liefert. Und in einigen Fällen gibt es keine andere Wahl, und Sie müssen sich nur mit dem zufrieden geben, was verfügbar ist.

Die meisten Protokolle ermöglichen eine gewisse Leistungsoptimierung, aber viele dieser Einstellungen sind nur serverseitig und stehen dem Durchschnittsbenutzer nicht zur Verfügung. (Und sie richtig zu konfigurieren, ist ein bisschen geheimnisvoll. Viele Systemadministratoren sind nicht bereit, sich damit herumzuschlagen.)

In den meisten Fällen können Sie die Leistung am einfachsten (manchmal sogar dramatisch) verbessern, indem Sie auf eine einfachere Desktop-Umgebung mit weniger Aufmerksamkeit verzichten und auf Hintergrundbilder verzichten.

Es gibt hauptsächlich zwei Gründe für langsame X11-Verbindungen, die Sie in Ihrer Frage angesprochen haben: Bandbreite und Latenz. Um zu verstehen, warum X11-Apps in einem Netzwerk langsam sind, gehen wir auf beide ein.

Bandbreite

X11 nimmt standardmäßig keine Komprimierung der Netzwerkdaten vor, die zwischen der Anwendung und dem Anzeigeserver übertragen werden. Wie Sie bereits erwähnt haben, können Sie die Option -C in SSH verwenden, um die Komprimierung zu aktivieren. Dies hilft zwar, ist jedoch nicht für die Komprimierung grafischer Daten optimiert. Im Vergleich zu Formaten wie H.264, die Komprimierungsraten von 100 zu 1 erzielen können, kann die -C-Komprimierung eine Komprimierung von 2 zu 1 erzielen. Eine bessere Lösung ist die Verwendung eines für Grafiken oder Videos optimierten Codecs für das X11-Video. Wir müssen jedoch darauf achten, dass es nicht zu verlustbehaftet wird, da Desktops im Allgemeinen schärfere Bilder als ein Film benötigen, damit der Benutzer den Text und die Informationen weiterhin klar lesen kann feine Details ausmachen.

Latenz

X11 weist in der Regel eine hohe Latenz auf, da die meisten Vorgänge mehrere Roundtrips zwischen der Anwendung und dem Anzeigeserver erfordern. Wenn Sie in einem LAN arbeiten, in dem die Ping-Zeiten weniger als eine Millisekunde betragen, machen sich diese mehrfachen Roundtrips nicht bemerkbar, über eine Internetverbindung summieren sie sich jedoch schnell auf.

Lösungen

Vor einigen Jahren wurden einige Projekte entwickelt, um die Bandbreiten- und Latenzprobleme des X11-Protokolls zu beheben. lbx (Low Bandwidth X) und dxpc (Differential X Protocol Compressor). Ich glaube nicht, dass lbx jemals viel Traktion bekommen hat, aber dxpc wurde zur zugrunde liegenden Technologie für ein Produkt namens NX . NX verwendet sowohl eine verlustbehaftete Komprimierung zur Reduzierung der Bandbreitenanforderungen als auch einen Differenzialalgorithmus und ein Caching, um die Anzahl der hin- und hergehenden Informationen zu reduzieren, die die hohe Latenz verursachen. Ich habe NX ziemlich oft verwendet und finde, dass die Leistung fast so gut ist wie bei lokalen Anwendungen. Wenn Sie Lust dazu haben, können Sie NX ausprobieren und sehen, ob es für Sie funktioniert. Der Nachteil ist, dass auf beiden Seiten der Verbindung Software installiert werden muss, während X11 in der Regel bereits installiert ist.