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.