L'origine du projet : combler les lacunes de X11 pour la gestion visuelle
Au milieu des années 80, le protocole X11 s'impose comme le standard pour les stations de travail Unix, mais il traîne un boulet assez gênant : sa gestion des images bitmap est rudimentaire. Le serveur X de base ne savait que copier des pixels d'un point A à un point B. Dès qu'il s'agissait de redimensionner une photo, de changer sa luminosité ou de convertir un format de couleur, c'était la catastrophe. Le processeur de la station de travail devait tout faire, puis renvoyer l'image entière, pixel par pixel, sur le réseau. Le truc c'est que les réseaux de 1988 tournaient souvent à 10 Mbps, ce qui rendait l'affichage d'une simple image haute résolution d'une lenteur exaspérante.
C'est là que le consortium X a décidé d'agir. L'idée derrière Xie était de déplacer l'intelligence du traitement d'image de l'application (le client) vers le serveur d'affichage. Au lieu d'envoyer une image décompressée de 2 Mo, l'application envoyait un flux compressé et une série d'instructions de traitement. Le serveur X, équipé de l'extension Xie, se chargeait alors de décompresser, de mettre à l'échelle et d'afficher le résultat. Sur le papier, c'était brillant. Dans la réalité, on s'est vite rendu compte que transformer un serveur d'affichage en moteur de retouche photo temps réel était un défi colossal qui allait diviser la communauté des développeurs pendant plus d'une décennie.
Comment fonctionnait techniquement l'architecture de Xie
Le concept du pipeline de traitement d'image
L'innovation majeure de Xie résidait dans son architecture en pipeline. Contrairement aux commandes X classiques qui sont exécutées de manière atomique, Xie permettait de construire des graphes de calcul. On définissait une source (un fichier, une zone mémoire), on y attachait des opérateurs (filtres, rotations, corrections gamma) et on terminait par une destination (une fenêtre à l'écran). Cette approche permettait d'économiser des allers-retours incessants entre le client et le serveur. Je reste convaincu que cette vision était très en avance sur son temps, préfigurant d'une certaine manière ce que nous faisons aujourd'hui avec les shaders sur nos cartes graphiques modernes, à ceci près que tout se passait en logiciel à l'époque.
La gestion des ressources et des types de données
Xie introduisait de nouveaux types d'objets côté serveur : les Photomaps et les Lut (Lookup Tables). Une Photomap n'était pas juste une grille de pixels, mais une structure de données capable de stocker des images dans différents formats de compression, comme le JPEG ou le CCITT Group 4 utilisé par les fax. Le serveur gérait lui-même la décompression. Le problème, c'est que cela demandait une mémoire vive considérable sur le serveur X, qui était souvent une machine avec peu de RAM. Résultat : le serveur swappait sur le disque, et le gain de performance espéré s'évaporait instantanément au profit d'un ralentissement global du système.
Les deux versions qui ont tout changé (ou presque)
Xie 4.1 : le sous-ensemble pour les terminaux X
Face à la complexité de la spécification complète, une version allégée appelée DIS (Document Imaging Subset) a vu le jour. Elle se concentrait uniquement sur ce dont les entreprises avaient besoin : l'affichage de documents scannés en noir et blanc. C'était l'époque où l'on commençait à numériser les archives papier massivement. Xie 4.1 a connu un certain succès commercial dans le monde de la gestion électronique de documents (GED). Les terminaux X de chez Tektronix ou NCD utilisaient cette extension pour permettre aux employés de consulter des fiches techniques ou des contrats sans faire exploser le réseau de l'entreprise. Là où ça coince, c'est que cette version était trop limitée pour les besoins multimédias qui commençaient à poindre.
Xie 5.0 : l'ambition démesurée de la version finale
La version 5.0 devait être le Graal. Elle supportait la couleur intégrale, des algorithmes de traitement complexes et une flexibilité totale dans la construction des pipelines. Mais honnêtement, c'est devenu une véritable usine à gaz. La spécification faisait des centaines de pages. Implémenter Xie 5.0 correctement demandait des mois de travail pour les constructeurs de matériel. De plus, l'arrivée de processeurs plus rapides comme le Pentium de chez Intel a commencé à rendre le concept de "déport de calcul" moins pertinent. Pourquoi s'embêter avec un protocole réseau complexe quand le processeur local peut traiter l'image en quelques millisecondes ?
Pourquoi Xie a fini par être abandonné par la communauté
Le déclin de Xie n'a pas été brutal, mais plutôt une lente érosion. Le premier facteur, c'est la maintenance du code. Le Sample Implementation (SI) fourni par le consortium X était d'une complexité effrayante, truffé de bugs et difficile à optimiser. Les développeurs de serveurs X libres, comme XFree86 (l'ancêtre de X.org), n'avaient tout simplement pas les ressources pour maintenir une telle extension alors que la demande des utilisateurs se déplaçait vers la 3D et le jeu vidéo.
Sauf que le coup de grâce est venu d'ailleurs. L'émergence de bibliothèques logicielles comme libjpeg ou libpng a permis aux développeurs d'intégrer le traitement d'image directement dans leurs applications de manière beaucoup plus simple et portable. On n'avait plus besoin que le serveur X sache ce qu'était un JPEG. L'application décompressait l'image et l'envoyait au serveur via l'extension MIT-SHM (Shared Memory), qui permettait de transférer des pixels très rapidement si le client et le serveur étaient sur la même machine. Et comme le modèle "terminal distant" perdait du terrain face au PC individuel, Xie a perdu sa raison d'être.
Comparaison : Xie vs Render vs OpenGL
L'approche de l'extension Render
Quelques années après l'abandon de Xie, l'extension Render a fait son apparition. Elle a pris le contre-pied total de son aînée. Là où Xie voulait tout faire (compression, traitement, géométrie), Render se concentre sur une seule chose : le dessin de glyphes et la composition d'images avec canal alpha (transparence). C'est beaucoup plus léger, plus facile à accélérer matériellement et cela répond aux besoins réels des interfaces graphiques modernes comme GNOME ou KDE. On est loin du compte avec les pipelines complexes de Xie, mais c'est précisément cette simplicité qui a fait le succès de Render.
Le rouleau compresseur OpenGL
Si Xie voulait être le processeur d'image du serveur X, OpenGL est devenu le processeur graphique universel. Avec l'arrivée des cartes graphiques grand public à la fin des années 90, la manipulation d'images est passée du CPU au GPU. Les fonctionnalités de mise à l'échelle ou de filtrage que Xie tentait d'implémenter laborieusement en logiciel sont devenues des fonctions de base câblées dans le silicium. Aujourd'hui, quand vous redimensionnez une fenêtre avec une image dedans, c'est OpenGL (ou Vulkan) qui fait le travail en une fraction de microseconde, rendant les concepts de Xie totalement obsolètes.
Les erreurs courantes et les idées reçues sur Xie
Confondre Xie avec un format de fichier
On entend souvent dire que Xie était un format d'image concurrent du GIF ou du JPEG. C'est une erreur totale. Xie ne stockait rien, c'était un protocole de transport et de manipulation. On ne pouvait pas avoir un fichier ".xie" sur son disque dur. C'est un peu comme si vous confondiez le protocole HTTP avec le contenu d'une page web. Xie était le tuyau et les outils de plomberie, pas l'eau qui coulait dedans.
Croire que Xie accélérait les graphismes 3D
Une autre confusion fréquente concerne la 3D. À l'époque, il existait une autre extension appelée PEX (PHIGS Extension to X) qui s'occupait de la 3D. Xie, lui, était strictement limité à la 2D et aux images bitmap. Si vous vouliez faire tourner un cube en fil de fer, Xie ne vous servait à rien. Il était là pour les photos, les scans de documents et éventuellement la vidéo primitive, mais rien de plus.
Questions fréquentes sur l'extension d'image X
Est-ce que Xie est encore présent dans les distributions Linux actuelles ?
Pour faire court : non. La plupart des distributions modernes utilisent X.org, qui a supprimé le support de Xie il y a bien longtemps, aux alentours de la version 6.8 du serveur X sortie en 2004. Si vous essayez de compiler un vieux programme qui dépend de Xie, vous allez vous heurter à des erreurs de liens manquants. Il existe bien des bibliothèques de compatibilité pour les systèmes legacy, mais pour le commun des mortels, Xie appartient au musée de l'informatique au même titre que les disquettes 5 pouces un quart.
Pourquoi les terminaux X l'adoraient-ils autant ?
Le truc, c'est que les terminaux X étaient des machines avec très peu de puissance de calcul locale. Ils avaient souvent des processeurs Motorola 68000 ou des RISC bas de gamme. Faire de la décompression d'image dessus aurait gelé l'interface pendant plusieurs secondes. En utilisant Xie, le terminal déléguait cette charge au serveur (qui était souvent une grosse machine Unix centrale). C'était une architecture client-serveur pure qui faisait sens dans les parcs informatiques centralisés des grandes banques ou des centres de recherche.
Peut-on simuler le comportement de Xie aujourd'hui ?
Oui, mais on ne le fait plus via une extension du serveur X. On utilise des protocoles comme VNC ou RDP qui intègrent nativement des algorithmes de compression d'image très performants. Mieux encore, les technologies de déport d'affichage modernes comme Wayland délèguent tout le rendu au client et se contentent de passer des descripteurs de mémoire (DMA-BUF). C'est beaucoup plus efficace et cela évite de transformer le serveur d'affichage en un monstre de complexité comme l'était Xie.
Verdict : une leçon d'ingénierie sur la sur-conception
Au final, Xie restera dans l'histoire de l'informatique comme l'exemple type de la "sur-conception" (over-engineering). En voulant créer un système capable de tout faire, les ingénieurs ont créé un monstre que personne ne pouvait maintenir correctement. L'industrie a préféré des solutions plus atomiques, plus simples et surtout plus proches du matériel. Mais il ne faut pas être trop sévère : Xie a permis de comprendre que le réseau est le goulot d'étranglement principal des systèmes distribués, une leçon que nous continuons d'appliquer aujourd'hui avec le streaming de jeux vidéo ou les interfaces web ultra-optimisées. Soit dit en passant, si vous croisez encore du code mentionnant XIE_PhotoMap dans un vieux script, vous saurez que vous manipulez un vestige d'une époque où l'on pensait que le serveur X allait conquérir le monde du traitement d'image.
Le problème, c'est qu'en informatique, la simplicité finit toujours par gagner. Xie était trop ambitieux pour son temps et trop complexe pour ses propres besoins. C'est précisément là que réside la beauté et la cruauté de notre métier : une idée géniale peut devenir un fardeau technologique en moins d'une décennie. Aujourd'hui, on rigole un peu en repensant aux pipelines de Xie, mais n'oublions pas que c'est sur ces échecs que se sont construits les standards solides que nous utilisons tous les jours sans même y penser.