12 de noviembre de 2010

En defensa de X.org

Entre la última entrada y los planes de Ubuntu -cuyo anuncio fue claramente planificado para fastidiar mi entrada- de usar Wayland en el futuro, se han dejado oir mil voces contra X.org. No tendría nada de malo (yo también lo hice un poco) si no fuera porque se han vuelto a repetir los mismos tópicos sobre la lentitud de X.org, sin especificar por qué razón en concreto. O, peor aun, achacándoselo a la "transparencia de red", el recurso favorito de quienes no tienen mucha idea de cómo funcionan las X.

Aunque fue diseñado como un protocolo, a X11 no hay que verlo como tal, sino más bien como una API cualquiera, expuesta por el servidor y utilizada por los clientes. En un sistema remoto, la librería libX11 abstrae las llamadas a esa API y las envía a través de red, pero en un sistema local se envían a través de un socket Unix. Que son muy rápidos, más que suficiente para implementar un sistema gráfico de alto rendimiento. ¿Adivinen que sistema de IPC utiliza Wayland para comunicar a los clientes con el servidor? Exacto, sockets Unix. De hecho, no sería difícil hacer que Wayland funcionara a través de un socket de red (aunque haría falta algún protocolo adicional para comunicar los buffers).


Es cierto que X11 es un protocolo anticuado, pero no es menos cierto se ha conservado bastante bien: No hubiera durado tanto de no ser así. Si, incluye cosas obsoletas y estúpidas como el dibujado de fuentes dentro del servidor,  pero a día de hoy nadie utiliza eso (las aplicaciones dibujan las fuentes en su propia ventana mediante freetype, ignorando por completo la API original de X11). Lo mismo con las operaciones gráficas (se recurre a Cairo). Para estar al día han sido necesarias las famosas extensiones, que en realidad son un ingenioso sistema para extender el protocolo (la API) sin romper la compatibilidad. Las extensiones pueden ser bastante radicales en cuanto a los nuevos modelos que introducen, por ejemplo, la extensión XRender se presentó como "un nuevo modelo de renderizado para X", y en la práctica, aunque sea retrocompatible, efectivamente viene a ser un servidor gráfico nuevo. Igual de radicales son la extensión Composite, Damage, Randr o DRI2. Incluso hay una extensión XFixes, cuyo objetivo es resolver problemas en el core de X11. Por extender, hasta sería posible intentar introducir un hipotético X12 como una extensión de X11.

Con esto quiero decir que X.org no está especialmente anticuado: parcheado hasta la saciedad si (lo cual no equivale a "bloated": mi /usr/bin/Xorg pesa tan solo 1.6M, y las extensiones no son mucho más grande), pero no "anticuado", al menos en el sentido de obsoleto. En la práctica, lo que más ha determinado el mal rendimiento de X.org han sido los drivers. X.org tiene un montón de código, una especie de subsistema, que los drivers utilizan para implementar las peticiones gráficas del servidor. Esta arquitectura y los drivers nunca han terminado de madurar, hace relativamente poco que se empezó a invertir en drivers libres para Linux, y gran parte de ese tiempo se ha dedicado a implementar KMS/GEM (el driver de Intel incluso perdió rendimiento en la transición). Es triste decir que aun hoy, hay tookits que en algunos casos son más rápidos haciendo por software lo que XRender hace mediante aceleración por hardware (además, XRender no tiene manera de notificar si los drivers están acelerando por hardware una operación gráfica o si se está recurriendo a un "fallback" de software, por lo que los toolkits algunas veces pasan de atreverse a usar XRender)

Pero si estuviera bien implementado, si hubiera una buena arquitectura y unos buenos drivers, un escritorio X.org no tendría grandes problemas de rendimiento. Hubo un intento (Xgl, del mismo autor de Compiz) de implementar el servidor X.org sobre OpenGL (básicamente, sustituir los drivers por Mesa), tras él hubo un intento de hacerlo de otra manera (Glucose). También hay quien ha experimentado con hacer con un Cairo-drm (con resultados muy prometedores). Ninguno de ellos maduró -y no porque no fueran buenas ideas-, pero hay que tener presente que nada, absolutamente nada de esto indica un problema en X11 como protocolo/API. De hecho, de haber tenido éxito quizás Wayland no existiría.

Con todo esto quiero decir que el principal problema de los gráficos en Linux es, y seguirá siendo, los drivers. Wayland tiene razón de ser, pero es solo una minúscula pieza de todo el sistema (9.332 líneas de código, incluyendo ejemplos). Para dibujar utiliza OpenGL-ES/Mesa, que no va a ser mágicamente mejor por el hecho de utilizarla un servidor gráfico nuevo, y cuyos drivers están sufriendo o van a sufrir reescrituras masivas debido a Gallium3D. La ventaja es que Wayland puede provocar un revulsivo que de más impulso a Mesa, a los toolkits y al resto de proyectos implicados, pero por lo demás, X.org no está tan maldito como algunos quieren hacer creer.

12 comentarios:

  1. Anónimo5:15 p. m.

    Supongamos que Wayland tiene éxito y resulta un revulsivo. Y que los drivers se pongan al día con Wayland. ¿Esto significaría una mejora también para X.org? (perdón por lo elemental de la pregunta)

    Sería interesante ver una lucha entre Wayland y X.org. A mí me ha parecido escuchar de esas mil voces que comentabas al principio que X.org ya estaba casi grogui ante Wayland.

    ResponderEliminar
  2. @Haller: "Depende". Wayland podría animar a trabajar a todo lo que está por debajo de él (el driver de Mesa/Gallium3D y el del kernel), pero no en el driver 2D de X.org. Para eso, X.org tendría que retomar Xgl/Glucose.

    X.org no está muerto, a Wayland aun le falta mucho (no hay más que ver el TODO que tienen), pero parece que por decirlo el señor Shuttleworth la gente se lo toma en serio.

    ResponderEliminar
  3. Anónimo9:12 p. m.

    Por decirlo el señor Shuttleworth y el señor Carmak.

    ResponderEliminar
  4. Anónimo12:32 a. m.

    Señor Carmack? Dios Carmack! :P

    ResponderEliminar
  5. Anónimo8:29 a. m.

    Muy buen artículo y muy bien analizado. Sin embargo obvias algo tan importante como es la sencillez de programar para X11 y sus extensiones, algo que parece que X11 no puede presumir precisamente. Con Wayland se pretende facilitar muchísimo la programación de drivers, lo que hará que estos sean más simples y sea más facil de depurar y mejorar. Si X11 fuese facil, ATi ya hubiese programado en condiciones su driver fglrx... Tanta extensión para X11 al final resulta ser caótico...

    ResponderEliminar
  6. Anónimo5:10 p. m.

    Muy buen artículo :D

    Me gustaría comentar una duda que tengo respecto a Wayland, he leido por ciertos foros que Wayland dejará en manos del toolkit de turno asuntos como la decoración de ventanas...

    ¿Qué papel juega en Wayland el gestor de ventanas? ¿Respetará los estándares ICCCM y EWMH?

    Espero que alguien pueda aclararme la duda, saludos

    ResponderEliminar
  7. Anónimo: Wayland no se mete en esos asuntos

    ResponderEliminar
  8. Anónimo12:33 a. m.

    ¿A que te refieres exactamente con que no se mete en esos asuntos?

    Porque claro, si nos cargamos de un plumazo X.org y con él los estándares para cosas tan importantes como el gestores de ventanas... ¿Quién se encarga entonces de gestionar el orden de ventanas en la pila, el tamaño, si requieren o no decoración, compatibilidad con taskbars/docks/pagers....?

    ResponderEliminar
  9. Anónimo: El compositor y/o el toolkit. En realidad las cosas no cambian mucho, simplemente cambian los actores de sitio y sus responsabilidades.

    ResponderEliminar
  10. Anónimo4:14 a. m.

    Hola Diego, gracias por tus aclaraciones :D

    Aun así (será que estoy demasiado acostumbrado a la programación bajo X11), sigo sin ver algunas cosas muy claras...
    Por ejemplo, supongamos que queremos portar Docky o similares a Wayland. Este tipo de aplicaciones puede saber la lista de ventanas y el ID de la ventana activa gracias a una serie de "atoms" almacenados en la ventana raíz (_NET_CLIENT_LIST y _NET_ACTIVE_WINDOW para ser más exactos). Adicionalmente estas ventanas poseen un tipo "especial" (_NET_WM_WINDOW_TYPE_DOCK) al que los gestores de ventanas responden, normalmente, no decorando la ventana y situándola en la cima de la pila...

    El toolkit desde luego no puede encargarse de esto... ¿Cómo va a hacer el toolkit que una de sus ventanas siempre esté en al cima si no hay un programa que se encargue de controlar que las otras no la tapen? Y si usamos en la misma máquina Qt y GTK buf, horror, uno no puede saber lo que hace el otro...
    Por no hablar de otras propiedades necesarias en un escritorio moderno como _NET_NUMBER_OF_DESKTOPS, _NET_DESKTOP_GEOMETRY, _NET_DESKTOP_VIEWPORT, _NET_CURRENT_DESKTOP, _NET_WORKAREA.....

    Si lo hace Wayland... ¿Qué ventaja aporta frente a X.org? ... no veo nada claro el cambio

    Y lo que tampoco veo por ningún lado es la documentación de Wayland xD ¿Alguien sabe donde puedo encontrar documentación sobre el API que ofrece Wayland de cara al desarrollador y de otros temas como gestión de ventanas etc?

    ResponderEliminar
  11. Anónimo: En Wayland existe un compositor integrado en el servidor, hay gente (por ejemplo, compiz) que está trabajando para que compiz pueda trabajar como un compositor de wayland. Ese ahí donde tendrá que implementarse todas esas cosas, pero ten en cuenta que hoy aun no hay ningún gestor de ventanas portado...

    La documentación sobre el diseño está aquí: http://cgit.freedesktop.org/wayland/tree/spec/main.tex

    ResponderEliminar
  12. Anónimo10:46 p. m.

    Gracias por el link Diego ;) Por lo que veo Wayland aun está muuuuuuuuuy verde y solo define el protocolo, habrá que esperar para tener algo similar a Xlib que nos facilite el trato con el protocolo de Wayland...

    Saludos y gracias!!

    ResponderEliminar