X11 - Reenvío y eficiencia

Tengo una aplicación gráficamente intensiva que debe enviarse a través de X11. Pasé un tiempo investigando X11 y su (in) eficiencia, incluida esta gran publicación: ¿Por qué el reenvío X11 es tan ineficiente? .

Una cosa que todavía no es clara para mí es si el rendimiento del reenvío X11 depende de la aplicación. Tenía la impresión de que toda la pantalla se reenvía, sin importar lo que esté sucediendo. Entonces el reenvío X11 debe ser independiente de la aplicación.

Entonces, ¿hay alguna información concreta sobre lo que realmente se reenvía y si el rendimiento de ssh -X depende de la aplicación?

xorg remote-access x11-forwarding

— Colmillo
fuente

"Entonces, ¿hay alguna información concreta sobre lo que realmente se reenvía y si el rendimiento de ssh -X depende de la aplicación?" Si. Para empezar, vea la charla de Daniel Stone La verdadera historia detrás de Wayland y X de LinuxConf.au 2013.

— sampablokuper

"Tenía la impresión de que se reenvía toda la pantalla" Es difícil entender qué le daría esa impresión, porque lo que la gente suele hacer con el reenvío SSH X es ejecutar manualmente aplicaciones individuales en el shell remoto; ¿Podrías explicar cómo estás iniciando las aplicaciones?

— rakslice

Un factor a tener en cuenta si está transportando la sesión X sobre un túnel SSH: ssh puede hacer compresión. Es la -Copción en la línea de comando o la Compression: yesopción en el archivo .ssh / config. Si está haciendo un reenvío tradicional de X desde Dallas a Australia a través de un enlace T1 congestionado, esta puede ser la diferencia entre tener la tarea de abrir un cuadro de diálogo de cinco niveles en la interfaz y seleccionar una casilla de verificación de una tarea poco realista a una muy simple frustrante dos horas Afortunadamente, no tuve la necesidad de probar esto con Wayland, pero supongo que ha mejorado mucho.

— Ed Grimm

No quiero comenzar una discusión extensa en los comentarios, especialmente porque mi pregunta ha sido respondida muy bien por @grawity. Por "toda la pantalla" quise decir que los datos reenviados a través del túnel ssh siempre serían una simple descripción de píxeles en la pantalla. @ EdGrimm: Gracias por su comentario sobre la compresión. Soy consciente de eso. En nuestro escenario particular, X11 se reenvía a través de un enlace LAN de 10 Gbit y la compresión / sin compresión parece no tener absolutamente ninguna diferencia.

— Fang

Tenía la impresión de que toda la pantalla se reenvía, sin importar lo que esté sucediendo. Entonces el reenvío X11 debe ser independiente de la aplicación.

No, en realidad es lo contrario. La razón por la cual el reenvío X11 se llama "reenvío X11" es porque transporta los mensajes de protocolo X reales utilizados por las aplicaciones para representar sus ventanas en el "servidor X" (generalmente Xorg). Esos mensajes son comandos para crear / mover ventanas, dibujar texto y primitivas gráficas (líneas / rectángulos), dibujar mapas de bits, etc.

Se podría decir que es conceptualmente lo contrario de los protocolos de "imagen de pantalla completa" como VNC / RFB. Creo que es algo comparable al RDP de Windows, que también se hizo para transportar comandos de dibujo GDI.

Entonces, las razones por las que ve diferencias entre programas son:

Para citar la publicación a la que ha hecho referencia, originalmente la mayoría de los programas basados en X funcionaban así:

Básicamente, X11 no envía la pantalla a su computadora, pero envía las instrucciones de visualización para que el servidor X en su computadora local pueda volver a crear la pantalla en su sistema local.

Entonces, cuando un programa quería mostrar un botón, solo enviaba algunos comandos breves: "dibujar un rectángulo", "dibujar texto" y quizás algunas líneas para que se vea en 3D.
Con el tiempo, esto cambió, los programas comenzaron a hacer el renderizado por sí mismos, y muchas de esas instrucciones se convirtieron en "aquí hay un mapa de bits que ya rendericé, póngalo en la pantalla", muy rápido localmente, pero muy lento en la red debido a que X11 carece de Compresión de imagen.

Esto significa que los programas creados con kits de herramientas modernos son mucho más lentos en X11 en red, incluso si es algo tan básico como las fuentes antialias.

(Por el contrario, RDP se ha adaptado con el tiempo e incluye varias formas de compresión de imágenes, como JPEG e incluso H.264; a menudo puede observar los artefactos de compresión mientras se carga la imagen completa).
Afortunadamente, la mayoría de los kits de herramientas de IU, como GTK, implementan el seguimiento de daños, por lo que solo se reenvían las regiones actualizadas. Sin embargo, algunos programas (como varias versiones de Firefox / Thunderbird) no admiten esto y solicitan una nueva representación completa de toda la ventana, incluso si realmente no se ha actualizado.

Esa es otra diferencia entre los programas: los que se comportan bien todavía son bastante utilizables en la red, pero los defectuosos pueden saturar un enlace de 100 Mbps sin hacer absolutamente nada útil.

— usuario1686
fuente

Recuerdo que una vez intenté configurar un servidor MythTV. La utilidad de "configuración" era una aplicación Qt y tardó varios minutos en mostrar cada página de configuración, a pesar de un enlace ADSL razonable como cuello de botella (casi 8 Mb / s). Debido a esto, el trabajo de unos minutos llevó varias horas: hubiera sido mucho más fácil con una interfaz de usuario de Curses o incluso una aplicación X11 con buen comportamiento. Si hubiera sabido cuántos problemas iba a ser, habría esperado una o dos semanas hasta que estuviese en el sitio y hubiera usado una de las cajas frontales sin disco para mostrar. Sin embargo, quería que el servidor funcionara antes.

— Toby Speight

En defensa de esos "programas con errores", uno debería señalar que esto es culpa de la ideología del kit de herramientas X +, que básicamente hace necesario que esos programas con errores tengan errores en primer lugar. Se podría pensar que un programa podría simplemente llamar a una API (que envía un comando) para tener una "ventana de aspecto normal", un menú y un botón aquí y una barra de desplazamiento allí, pero no. Usted, o el conjunto de herramientas, debe hacer todo a mano. Realmente no soy un gran admirador de la EM y menos aún de Apple, pero han acertado con esas cosas, mientras que el ecosistema X ha apenado durante décadas, y todavía apesta.

— Damon

Sin embargo, no estoy seguro de si hay alguna diferencia. ¿Qué hace que UWP o WinForms de Windows o comctl32 sean menos un "kit de herramientas" que GTK y QT? ¿No hacen también todo "a mano"?

— usuario1686