Le skeuomorphisme, un problème de rendu, pas une blague

Voici une affirmation qui va agacer les deux camps : le skeuomorphisme n'est jamais mort parce que les utilisateurs le détestaient. Il est mort parce qu'il coûtait cher, en pixels, en cycles GPU et en heures de designer, et le design plat a gagné pour des raisons économiques, pas esthétiques. Un nouveau projet qui fait le tour du web, DEsk, un bureau Wayland skeuomorphique complet pour Linux où les fenêtres sont des feuilles de papier posées sur un bureau en noyer ray-tracé, est le premier vrai test de cette thèse depuis des années. Et il prouve le point à merveille : dès que vous décidez que toute la pièce est éclairée par une seule lampe de bureau, vous vous engagez dans une architecture de rendu qui ressemble bien plus à celle d'un moteur de jeu qu'à celle de GNOME Shell.

Ce que doit réellement rendre un bureau skeuomorphique

Le design plat est clément pour un moteur de rendu. Un compositeur moderne comme Mutter ou KWin passe l'essentiel de son temps à faire de la composition de textures : les applications vous fournissent des buffers, vous dessinez des quads, vous appliquez un shader pour les coins arrondis et une ombre portée, et c'est fini. Toute la frame est pratiquement gratuite sur n'importe quel GPU sorti depuis une décennie, et c'est exactement pour ça que l'UI plate a tout raflé : elle ne coûte rien et s'adapte à n'importe quelle résolution avec une simple transformation.

Le skeuomorphisme brise chaque partie de ce contrat. Dès que votre langage de design dit « cette fenêtre est une feuille de papier crème avec des fibres, une épaisseur et un coin corné », vous avez besoin de :

• Ombrage matériel — le papier n'est pas une couleur, c'est une réponse diffuse proche de la diffusion sous-surfacique, avec une texture de fibres. C'est du calcul par pixel, pas un simple rectangle plein.
• Éclairage cohérent — chaque objet de la scène doit s'accorder sur la position de la lumière. Une seule lampe implique une seule shadow map (ou une seule requête de rayon) à laquelle tout participe, y compris le contenu en direct des fenêtres.
• Ombres de contact — une fenêtre « posée sur un bureau » a besoin d'occlusion ambiante là où le papier rencontre le noyer, sinon l'illusion s'effondre instantanément.
• Déformation — DEsk vous permet de soulever le coin de la feuille pour voir le dos, et de froisser les fenêtres en boule quand vous les fermez. C'est du déplacement de sommets sur une texture en direct, pas une simple animation d'échelle.

Rien de tout cela n'est individuellement difficile. Les moteurs de jeu le font depuis des décennies. Mais un compositeur de bureau a des contraintes qu'un jeu n'a pas : le contenu de ces « feuilles de papier » est une sortie d'application arbitraire, mise à jour jusqu'à 60 images par seconde, et vous ne pouvez rien pré-calculer à son sujet. Vous êtes en train d'ombrer un flux vidéo en direct comme s'il s'agissait d'encre sur du papier fibreux.

Le compositeur devient un moteur de jeu

La documentation d'architecture de DEsk décrit ce choix sans détour : la pièce (bureau, étagère, console, boîte aux lettres) est ray-tracée sur le GPU via GLES 3, avec un tracer CPU en secours, et le résultat est mis en cache par taille d'écran. Cette seule phrase contient toute la stratégie d'ingénierie, et elle mérite d'être détaillée, car c'est la seule façon raisonnable de faire les choses.

Le truc, c'est la séparation statique/dynamique. Ray-tracer la pièce à chaque frame serait absurde : même un path tracer modeste met des secondes par frame sur du matériel milieu de gamme. Mais la pièce est statique. Le bureau ne bouge pas, la lampe non plus. On la trace donc une seule fois à la connexion (« la première connexion dessine la pièce une fois : quelques secondes sur un GPU, bien plus sans »), on met la radiance en cache, et ensuite la pièce n'est plus qu'un fond texturé. Les objets dynamiques (fenêtres en papier, tiroir, lettres dans la boîte aux lettres) sont rendus en forward par-dessus, éclairés pour s'accorder à la scène en cache.

// Sketch of the two-layer architecture a skeuomorphic shell converges on
struct frame {
// Layer 1: the room. Traced once at login, cached per output size.
texture room_cache;          // desk, shelf, post box, baked lamp light
// Layer 2: dynamic objects, forward-rendered each frame.
vector<object> paper_windows; // app buffers mapped onto paper quads
vector<object> drawer_items;
vector<object> notifications;
};
void render(frame *f) {
blit(f->room_cache);                       // one textured quad, nearly free
for (auto &o : f->paper_windows)
draw_paper(o);                         // fibre shader + fake AO + dog-ear
composite(f->drawer_items, f->notifications);
}

C'est exactement, et ce n'est pas un hasard, le fonctionnement de Myst en 1993 : des scènes pré-rendues de manière statique, avec des sprites dynamiques composités par-dessus. Plusieurs observateurs ont noté que DEsk dégage des « vibes Myst » très marquées, et ils ont plus raison qu'ils ne le croient : il ne s'agit pas seulement d'une parenté esthétique, mais de la même architecture de rendu, adoptée parce que les mêmes contraintes (illumination globale coûteuse, composition bon marché) tiennent toujours. Le passionné d'histoire qui est en moi adore ça. Trente ans de progrès GPU, et la réponse honnête à « comment ray-tracer mon bureau ? » reste toujours « ne le faites pas, tracez-le une fois et trichez ».

Le design multi-écrans montre le même pragmatisme. Plutôt que de ray-tracer une pièce plus grande pour chaque écran, les écrans supplémentaires affichent « d'autres planches du bureau, qui se prolongent » : le fond statique s'étend, et la scène en cache est amortie sur toutes les sorties. Un écran débranché en pleine session voit simplement ses fenêtres rattachées à un écran restant. Simple, mais cela contourne le problème vraiment difficile de devoir re-tracer à chaque événement de branchement à chaud.

Le skeuomorphisme alourdit le GPU d'une manière que le design plat ne connaît jamais

Soyons concrets sur ce surcoût, parce que « c'est plus lourd » fait beaucoup de travail non mérité dans la plupart des discussions sur ce style. Comparons ce que fait un compositeur plat pour une fenêtre avec ce qu'exige la métaphore du papier de DEsk :

Plat : lier le wl_buffer du client comme texture, dessiner un quad avec un shader qui l'échantillonne, éventuellement arrondir les coins avec une fonction de distance signée, appliquer une ombre à 9 taps bon marché. Coût par fenêtre : une poignée de lectures de texture par pixel, toutes dans des zones favorables au cache.

Papier : le buffer du client n'est que l'« encre ». Il faut aussi une couche de base en papier (texture de fibres, assombrissement des bords, épaisseur), un coin corné qui est une géométrie pliée distincte avec son propre éclairage, une ombre de contact sur le bureau qui dépend de la position de la fenêtre dans la scène, et un éclairage qui s'accorde avec la lampe intégrée au cache de la pièce. Et quand l'utilisateur tire un bord pour « sortir plus de papier », le quad de papier se redimensionne indépendamment du contenu : vous avez découplé la géométrie de la fenêtre de la géométrie de la surface, ce qu'aucun compositeur classique ne fait.

Le vrai coût, pourtant, n'est pas le débit : les GPU modernes se moquent de quelques couches de textures en plus. C'est la complexité du pipeline. Le budget de shaders d'un compositeur plat tient en un ou deux programmes pour toute la session. Une coque skeuomorphique a besoin d'un petit système de matériaux : papier, noyer, laiton, verre (les lentilles de la lampe de l'horloge), tissu. Chaque matériau est une variante de shader ; chaque variante peut casser sur un pilote donné ; et chacune interagit avec l'éclairage partagé de la lampe, si bien qu'elles ne peuvent pas être conçues isolément. C'est pour cela que l'époque des thèmes d'Enlightenment et de GTK2 est morte, et c'est le contre-argument le plus solide chez les praticiens : le gestionnaire de fenêtres est la partie facile. Chaque application dessine toujours son contenu avec GTK ou Qt, et aucune quantité de noyer côté compositeur ne fera ressembler une appli libadwaita à un objet appartenant à un vrai bureau. DEsk ne résout ceci que partiellement : les fenêtres à décoration côté client « reposent aussi sur du papier », ce qui signifie que la métaphore enveloppe les applications sans vraiment les transformer.

Wayland rend ceci à la fois plus facile et plus difficile

Si un projet comme celui-ci existe aujourd'hui et non en 2010, c'est pour une raison. Le pari architectural central de Wayland (le compositeur possède toute la frame, chaque pixel passe par lui) est exactement celui qu'une coque skeuomorphique doit faire. Sous X11, une application pouvait dessiner où elle voulait, et le mieux qu'on pouvait faire était un gestionnaire de composition qui rattachait désespérément les fenêtres en croisant les doigts. Sous Wayland, la coque reçoit des buffers de surface propres et isolés, et a une liberté totale sur la manière de les présenter. Si vous voulez projeter une surface sur une feuille de papier déformable avec un coin corné, Wayland est le premier système d'affichage où c'est simplement difficile plutôt qu'incohérent.

Mais Wayland alourdit aussi la facture. Un environnement de bureau n'est pas un moteur de rendu ; c'est un moteur de rendu plus vingt ans d'accumulation de protocoles : Xwayland pour les applications héritées, le pont IBus pour les méthodes de saisie (DEsk permet de taper dans l'index de la bibliothèque et dans le bloc-notes), PipeWire pour le bouton de volume, logind pour la luminosité et la gestion du capot, MPRIS pour la page média de l'horloge, PAM pour l'écran de verrouillage. Chacune de ces intégrations est une surface que GNOME répartit sur des centaines de contributeurs. DEsk trace une ligne claire, « ce qu'il fabrique et ce qu'il emprunte », en déléguant le réseau, le Bluetooth, l'impression et le thème des autres applications à des logiciels libres existants. Cette stratégie d'emprunt est la seule façon pour une petite équipe de livrer un bureau complet, mais elle signifie que l'illusion skeuomorphique s'arrête brutalement aux bords : les paramètres Wi-Fi sont un panneau GTK plat qui appartient à quelqu'un d'autre.

À noter pour ceux qui seraient tentés d'essayer : comme la pièce est mise en cache par taille d'écran et que la couche dynamique est un simple forward rendering GLES 3, le coût en régime établi devrait être sans surprise, comparable à celui de tout compositeur qui fait des effets lourds. Les points douloureux sont le tracé au login sur les machines sans GPU (le repli CPU existe, et il est lent) et la rugosité générale d'une bêta v0.1 : les testeurs signalent des animations incohérentes sur les contrôles à état, comme le bouton d'alimentation du Panneau de configuration, ce qui, dans une interface skeuomorphique, n'est pas un bogue cosmétique. Quand l'animation de rotation de la clé se déclenche mal, on ne sait pas si la machine va vraiment s'éteindre. Le skeuomorphisme augmente les enjeux de la justesse des animations, car l'animation est l'indicateur d'état. La grande vertu méconnue du design plat, c'est qu'un interrupteur n'a que deux états dessinables et aucun entre-deux.

Pourquoi nous avons arrêté de construire comme ça

Le récit habituel dit que le skeuomorphisme était une béquille (des métaphores au rendu réaliste pour apprendre aux gens à utiliser les écrans tactiles) et qu'une fois les utilisateurs devenus adultes, on a jeté les coutures en cuir. Cette histoire est en grande partie fausse, et DEsk est utile précisément parce qu'il révèle la véritable économie du sujet. Le skeuomorphisme est mort lorsque deux choses se sont produites en même temps : les écrans Retina ont quadruplé le nombre de pixels que les textures peintes à la main devaient couvrir, et le mobile a fait tourner les interfaces sur des GPU contraints, alimentés par des batteries. Le vectoriel plat s'adapte gratuitement ; une texture de métal brossé en 1x, 2x et 3x, non. La refonte d'iOS 7 n'était pas une évolution du goût ; c'était une réduction drastique du budget de rendu. Si vous avez lu comment les terminaux accélérés par GPU sont passés des grilles de glyphes TTY aux pipelines de shaders complets, vous avez vu le même compromis depuis l'autre côté : on dépense le GPU sans compter à l'intérieur du contenu d'une application, mais le chrome lui-même a été mis au régime.

Il y a aussi une raison plus profonde, qui n'a rien à voir avec les GPU : la cohérence ne se compose pas. Un designer peut créer une magnifique métaphore physique ; un millier de développeurs tiers ne le peuvent pas. La métaphore de la bibliothèque fonctionne pour les applications propres à DEsk. Dès que Firefox affiche sa propre interface grise et plate sur le papier, vous regardez une capture d'écran scotchée sur un accessoire. Le fil Hacker News a pointé cela sous deux angles à la fois : un commentateur nostalgique de l'ère des thèmes de GTK2, un autre remarquant que les boîtes à outils modernes « semblent conçues pour résister aux thèmes ». Le bureau peut être un bureau ; les applications, jamais. La métaphore fuit, et quiconque a construit un environnement thématisé sait que cette fuite est fatale à l'illusion. C'est le même écart qui rend les anti-patterns UX si tenaces : la surface est facile à corriger, l'écosystème non.

Où l'affirmation à contre-courant se brise

J'ai dit que le skeuomorphisme avait perdu pour des raisons économiques, et je le crois. Mais l'honnêteté impose des concessions, et les aspérités de DEsk les fournissent.

D'abord, une partie du coût n'a rien à voir avec le rendu : c'est une ambiguïté d'interaction. Une métaphore physique emprunte les attentes du monde réel de l'utilisateur, et la physique n'a pas d'annulation. Quand fermer une fenêtre consiste à la « froisser en boule et la jeter », c'est charmant une fois et légèrement inquiétant la quarantième fois où vous fermez réflexivement la mauvaise fenêtre. L'abstraction du chrome plat est une fonctionnalité : une petite croix est une promesse, pas une performance. Ensuite, l'état. Les objets physiques doivent toujours ressembler à ce qu'ils sont ; une animation de clé bloquée n'est pas une transition saccadée, c'est un mensonge sur le fait que votre machine va s'éteindre ou non. Une interface skeuomorphique doit être juste là où l'UI plate peut se permettre d'être approximative, et la justesse des animations coûte terriblement cher en temps de QA, comme le sait trop bien quiconque a livré des systèmes où l'interface doit refléter fidèlement un état distribué.

La grande vertu méconnue du design plat, c'est qu'un interrupteur n'a que deux états dessinables et aucun entre-deux. Une clé en laiton en a une infinité, et chacune d'elles est un rapport de bogue en puissance.

Troisièmement, l'accessibilité et la découvrabilité jouent dans les deux sens. Plusieurs commentateurs ont suggéré qu'une métaphore de bureau littérale pourrait réellement aider les utilisateurs âgés qui n'ont jamais construit de modèle mental des systèmes de fichiers : ils apprennent où cliquer par cœur et ne peuvent pas se rattraper quand cela change, car l'UI plate « n'a aucune logique intrinsèque pour eux ». Un bureau a une logique : les lettres vont dans la boîte aux lettres, les documents sont du papier, ce qu'on garde va dans le tiroir. C'est un argument sérieux, et le rejeter comme de la nostalgie est paresseux. Mais la même physicalité qui aide un utilisateur cache des fonctionnalités à un autre : comment découvrir que Super+D ouvre le tiroir, ou qu'une fenêtre pliée peut y être rangée ? Les affordances physiques fonctionnent quand les objets sont à portée de main ; les raccourcis clavier sont de l'abstraction pure apprise, dans tous les cas.

À quoi sert vraiment DEsk

Ce serait une erreur de lire DEsk comme une proposition de travailler tous sur des bureaux ray-tracés dès maintenant. Cela n'arrivera pas, et l'économie évoquée en introduction tient toujours : un éditeur de plateforme qui livre à un milliard d'appareils ne peut pas se permettre des shaders de matériaux par pixel sur le chrome, un éclairage de lampe réglé à la main et des clés en laiton à animation juste. Le design plat reste le choix par défaut pour les logiciels système, comme le béton est le choix par défaut pour les ponts.

Ce que DEsk démontre vraiment, c'est une chose dont le bureau Linux avait besoin de voir la preuve depuis une décennie : la couche de composition est désormais assez expressive pour devenir un médium. Wayland associé à un GPU moderne offre à un développeur déterminé une toile plein écran avec assez de marge pour rendre un monde cohérent, et pas seulement agencer des rectangles. La technique de l'ère Myst (cuire la lumière coûteuse, rendre la couche dynamique en forward) comble l'écart de performance qui rendait cela impossible. Que le monde que quelqu'un construit soit un bureau en noyer nostalgique, le poste de pilotage du Nostromo dont rêvait un commentateur, ou quelque chose que personne n'a encore imaginé, c'est une affaire de goût. La capacité, elle, est la nouvelle.

Un schéma se répète en informatique : une technologie arrive à maturité, son courant dominant converge vers l'esthétique la moins chère mais suffisante, puis des passionnés redécouvrent les esthétiques coûteuses comme une forme d'artisanat. C'est arrivé avec les claviers mécaniques, avec les images tramées en un bit, avec les shaders CRT dans les émulateurs. Les bureaux skeuomorphiques sont la prochaine étape de cette file. Ils ne remplaceront rien. Ils nous rappelleront simplement, comme la seule lampe de bureau de DEsk éclairant toute une pièce ray-tracée, que le rectangle gris plat a toujours été une décision budgétaire, et que les budgets, contrairement aux goûts, peuvent se discuter.