Terminaux GPU : des TTY aux atlas de glyphes

En 1978, Digital Equipment Corporation sort le VT100. C'était un meuble à part entière : un écran CRT dans un boîtier beige, relié à un mini-ordinateur par câble série. Il n'exécutait aucun programme et ne savait pas afficher de graphismes. Il affichait du texte dans une grille fixe de 80 colonnes sur 24 lignes, et c'était toute l'interface entre un humain et un système en marche. Près de cinquante ans plus tard, ce que les développeurs regardent toute la journée reste, conceptuellement, cette même grille. Mais l'architecture sous-jacente a changé d'une façon que les concepteurs du VT100 n'auraient pas imaginée. La dernière génération d'émulateurs de terminal — Ghostty, Alacritty, Kitty, WezTerm — envoie le texte à travers des pipelines de rendu GPU conçus à l'origine pour les jeux vidéo. Et la différence de performance n'est pas incrémentale. Elle est structurelle.

Pourquoi votre terminal par défaut est un goulot d'étranglement

Terminal.app sous macOS, GNOME Terminal sous Linux, Console Windows : ils sont livrés avec votre OS et ils font le travail. Pendant des années, cela a suffi. On tapait des commandes, on lisait la sortie, et on passait à la suite. Mais les workflows des développeurs ne ressemblent plus à ça. On diffuse des logs de build verbeux, on lance des applications TUI comme lazygit et btop qui redessinent tout l'écran à chaque frappe, on redirige la sortie structurée d'outils de code IA et on gère plusieurs volets de sorties concurrentes. Les terminaux historiques n'ont jamais été conçus pour ça.

La cause est simple : un rendu limité par le CPU. Les terminaux historiques dessinent le texte via les API de texte de la plateforme, qui traitent les caractères séquentiellement. Quand une suite de tests envoie dix mille lignes d'un coup, le terminal doit rastériser chaque glyphe sur le CPU, le composer dans un framebuffer puis pousser le résultat à l'écran, le tout sur le thread principal. Les images sautent. La latence de saisie grimpe. Le défilement devient poussif. On le ressent, ce petit coup de frein quand on fait un cat sur un gros fichier.

Ce n'est pas un simple désagrément. La latence de saisie influence directement la vitesse de votre réflexion. Les études sur la latence entre frappe et affichage montrent que des délais supérieurs à 10 millisecondes sont perceptibles, et que ceux au-delà de 50 millisecondes ralentissent mesurablement la frappe. Si votre terminal ajoute 20 à 30 ms de latence par-dessus le rendu de votre éditeur, vous pensez littéralement plus lentement que vous ne le devriez.

Comment fonctionne réellement le rendu de terminal accéléré par GPU

Envoyer du texte à un GPU ressemble à utiliser une masse pour planter une punaise. Des caractères à chasse fixe dans une grille fixe, qu'est-ce qui peut être si compliqué ? Mais l'idée derrière les terminaux accélérés par GPU n'est pas que le rendu de texte soit difficile. C'est que les GPU sont terriblement efficaces pour exécuter la même petite opération des milliers de fois en parallèle, exactement ce dont le rendu de terminal a besoin : estampiller des textures identiques de la taille d'un glyphe dans une grille, des milliers de cellules par image.

L'astuce, c'est l'atlas de glyphes. Quand un caractère apparaît pour la première fois, le terminal le rastérise (avec FreeType, CoreText ou DirectWrite selon la plateforme) et stocke le bitmap obtenu dans une texture atlas sur GPU, une grande planche de sprites de caractères prérendus. À chaque image suivante, afficher ce caractère revient simplement à une lecture de texture et à un dessin de quad. Pas de rastérisation, et le CPU ne fait rien de plus que transmettre les données de la grille. C'est la même technique que les moteurs de jeu utilisent depuis des décennies pour afficher du texte dans des scènes 3D.

Terminal Rendering Pipeline:
PTY byte stream
→ VT parser (interprets ANSI escape sequences)
→ Cell grid (char + fg color + bg color + attributes per cell)
→ Glyph atlas lookup (GPU texture coordinates for each character)
→ Batch draw calls (one draw per distinct texture/color combination)
→ GPU compositing (text + cursor + selection + background effects)
→ Displayed frame
The expensive step in legacy terminals — per-glyph CPU rasterization —
becomes a cache hit in the atlas. That's the whole trick.

L'API de rendu varie selon la plateforme. Alacritty et WezTerm utilisent OpenGL sous Linux et Metal sous macOS. Ghostty dispose d'un backend Metal maison sous macOS et prend en charge Vulkan sous Linux. Kitty utilise OpenGL partout. Le choix compte pour la portabilité et la compatibilité des pilotes, mais toutes ces approches partagent le même avantage fondamental : elles transforment le rastérisation par image en un problème d'échantillonnage de textures par lots, que les GPU résolvent presque gratuitement.

Comparatif des terminaux accélérés par GPU : Ghostty, Alacritty, WezTerm et Kitty

Ces quatre terminaux partagent une philosophie de rendu mais divergent fortement sur tout le reste. Chacun répond différemment à la question : que doit faire un terminal ?

Ghostty — Interface native, sans compromis

Ghostty de Mitchell Hashimoto est écrit en Zig, avec une intégration d'interface native à la plateforme : AppKit et Metal sous macOS, GTK sous Linux. Là où la plupart des terminaux multiplateformes se ressemblent sur tous les OS (ce qui signifie aussi qu'ils paraissent étrangers partout), Ghostty respecte les conventions de chaque plateforme pour la gestion des fenêtres, les raccourcis clavier et le style visuel. Il se comporte comme une application macOS sur macOS et comme une application GNOME sous GNOME. Ça peut sembler un détail cosmétique, mais quand votre terminal est l'application dans laquelle vous passez le plus de temps, la sensation native s'accumule sur des mois.

Alacritty — Faire une seule chose, la faire vite

Alacritty a lancé le mouvement des terminaux accélérés par GPU. Écrit en Rust, il omet délibérément les onglets, les découpages et le multiplexage intégré. La philosophie est d'inspiration Unix : bien faire une seule chose et laisser d'autres outils s'occuper du reste. Si vous utilisez déjà tmux ou un gestionnaire de fenêtres en mosaïque, Alacritty vous offre le rendu brut le plus rapide avec la plus petite empreinte. Il ne gagnera pas un comparatif de fonctionnalités, et c'est justement le but.

WezTerm — Le couteau suisse, bien fait

WezTerm adopte la position inverse. Multiplexage intégré, intégration SSH, configuration en Lua, prise en charge des ligatures, rendu d'images : c'est un terminal maximaliste. Son moteur de script Lua est vraiment puissant ; vous pouvez écrire des raccourcis conditionnels, des titres d'onglets dynamiques et une logique de changement d'espace de travail qui nécessiteraient trois ou quatre outils séparés dans d'autres configurations. Si vous voulez une seule application pour remplacer votre terminal, votre multiplexeur et la moitié de vos scripts de dotfiles, WezTerm est celui à essayer.

Kitty — Le pionnier des protocoles

La contribution la plus durable de Kitty n'est pas son moteur de rendu, ce sont les protocoles. Le protocole graphique de Kitty permet aux applications d'afficher des images raster en ligne. Le protocole clavier de Kitty résout enfin le problème vieux de plusieurs décennies de la reconnaissance ambiguë des touches (essayez de distinguer Ctrl+I de Tab dans un terminal classique, c'est impossible). Ces protocoles ont été adoptés par d'autres terminaux et par des frameworks TUI comme Textual et Ratatui. Kitty a fait avancer tout l'écosystème, et les outils que vous utilisez aujourd'hui sont meilleurs grâce à lui.

Benchmarks de performance des terminaux : ce qui compte et ce qui ne compte pas

Les benchmarks de terminaux sont faciles à mal faire. Faire un cat d'un énorme fichier dans le terminal et chronométrer l'opération mesure le débit, mais ce n'est pas la métrique qui affecte votre expérience quotidienne. Trois chiffres comptent vraiment.

Latence de saisie : le délai entre l'appui sur une touche et son affichage à l'écran. Les terminaux GPU atteignent régulièrement 2 à 5 ms. Les terminaux historiques tournent autour de 15 à 30 ms. Vous le ressentez à chaque frappe.
Régularité des images : pas seulement les FPS moyens, mais leur variance. Un terminal qui affiche 60 fps mais tombe à 15 fps pendant une forte sortie paraît pire qu'un terminal qui maintient 30 fps stables. La composition GPU gagne ici, car le coût du rendu reste presque constant quelle que soit la part de l'écran qui change.
Consommation au repos : un terminal ouvert avec une invite de shell ne devrait pas consommer de CPU de manière significative. Certains terminaux GPU ont eu au départ des problèmes de consommation électrique à vide à cause de redessins inutiles, mais c'est largement réglé. Alacritty et Ghostty tournent typiquement à 30 à 60 Mo de mémoire au repos. WezTerm en utilise 80 à 150 Mo à cause de son runtime Lua.

# Quick throughput test — not the most important metric,
# but reveals rendering architecture differences
time seq 1 1000000 | head -c 10M > /dev/null  # baseline
time seq 1 1000000                              # terminal-limited
# Measure input latency with Typometer (Java) or similar
# https://github.com/pavelfatin/typometer
#
# Typical results on modern hardware:
#   Ghostty:      2-4ms
#   Alacritty:    2-4ms
#   Kitty:        3-5ms
#   WezTerm:      4-6ms
#   Terminal.app: 15-25ms
#   GNOME Term:   20-30ms
# For frame consistency, vtebench is the best tool:
# https://github.com/alacritty/vtebench
vtebench --benchmark scrolling --iterations 100

Le terminal le plus rapide n'est pas forcément le meilleur. C'est celui dont les compromis correspondent à votre façon réelle de travailler. Un utilisateur expert de tmux a des besoins différents de quelqu'un qui s'appuie sur les découpages natifs, et les deux diffèrent de quelqu'un qui vit dans le terminal intégré de VS Code.

Multiplexage intégré contre tmux : un avis pragmatique

C'est la question qui déclenche les débats. Votre terminal doit-il gérer les découpages et les onglets, ou faut-il laisser ça à tmux ? Je vais éviter les demi-mesures : les deux approches sont bonnes, et la bonne réponse dépend d'une seule variable : avez-vous besoin de persistance de session ?

Les sessions tmux survivent aux plantages du terminal et aux déconnexions SSH. Les découpages natifs, non. Si vous vous connectez en SSH sur des serveurs de production et que vous devez vous détacher puis vous rattacher, tmux est incontournable. Rien d'autre ne le fait aussi fiablement.

Mais pour le développement local, le multiplexage natif a un vrai avantage. Les découpages natifs sont composés par le GPU : le terminal dessine tous les volets directement dans une seule image. Faire tourner tmux dans un terminal GPU signifie un double rendu : tmux dessine son écran virtuel dans un tampon de caractères, puis le terminal re-dessine ce tampon sur le GPU. Vous payez une taxe de performance, et vous perdez l'accès à des fonctionnalités modernes comme les images en ligne et le protocole clavier de Kitty, car tmux se place entre votre application et votre terminal sans relayer proprement ces protocoles.

La démarche pragmatique est hybride : découpages natifs pour le travail local, tmux pour les sessions distantes. Utilisez le bon outil pour chaque contexte plutôt que de forcer un seul outil à tout gérer.

Les protocoles de terminal modernes qui ouvrent de nouveaux workflows

Le VT100 définissait un ensemble de séquences d'échappement que les terminaux supportent depuis des décennies. Les terminaux modernes étendent ces séquences avec de nouveaux protocoles qui permettent des workflows que les concepteurs d'origine n'avaient jamais imaginés.

L'affichage d'images en ligne via le protocole graphique de Kitty ou Sixel permet aux outils en ligne de commande d'afficher des graphiques, des diffs et des diagrammes sans ouvrir de navigateur ni de fenêtre séparée. Les outils de data science peuvent tracer directement dans le terminal. Les assistants de code IA peuvent afficher une sortie visuelle en ligne. Ça semble gadget jusqu'à ce que vous l'utilisiez, et là, ça paraît évident.

La sortie synchronisée (mode 2026, par coïncidence) permet aux applications de regrouper les mises à jour d'écran en images atomiques. Sans elle, une application TUI qui redessine toute son interface (gestionnaire de fichiers, tableau de bord, éditeur de texte) produit un scintillement visible, car le terminal affiche chaque séquence d'échappement à mesure qu'elle arrive. Avec la sortie synchronisée, le terminal met en tampon tout ce qui se trouve entre un marqueur de début et un marqueur de fin, puis l'affiche d'un seul coup. Des frameworks comme Ratatui et Textual l'activent automatiquement lorsque le terminal le permet.

# Test Kitty keyboard protocol support
printf '\e[?u'  # Query keyboard protocol flags
# Test Kitty graphics protocol support
printf '\e_Gi=31,s=1,v=1,a=q,t=d,f=24;AAAA\e\\'
# Synchronized output — bracket your screen updates
printf '\e[?2026h'  # Begin synchronized update
# ... application writes to screen ...
printf '\e[?2026l'  # End — terminal renders everything at once

Le protocole clavier de Kitty mérite une attention particulière. La gestion du clavier dans les terminaux est cassée depuis quarante ans. Le VT100 encodait Ctrl+I et Tab avec le même octet (0x09). Échap et les touches modifiées par Alt commencent toutes par 0x1b. Le protocole Kitty remplace cela par un rapport d'événements clavier sans ambiguïté : appui, relâchement et répétition, avec les informations complètes sur les modificateurs. Neovim, Helix et d'autres éditeurs le prennent déjà en charge. Une fois que vous avez utilisé un terminal où Ctrl+Shift+Entrée fonctionne comme un raccourci distinct, vous ne pouvez plus revenir en arrière.

Configurer un terminal accéléré par GPU pour gagner vraiment en productivité

Installer un terminal rapide et le laisser avec ses réglages par défaut ne vous donne peut-être que 30 % du bénéfice. Le reste vient de la configuration. Voici ce qui compte vraiment.

Le choix de la police influence la lisibilité, la taille de l'atlas de glyphes et le comportement des ligatures. JetBrains Mono, Fira Code et Monaspace sont des choix populaires avec prise en charge des ligatures. Si vous utilisez une variante Nerd Font, vous obtenez des icônes dans votre invite de shell, votre gestionnaire de fichiers et vos outils git. Ghostty, WezTerm et Kitty prennent tous en charge les ligatures ; Alacritty ne le fait pas délibérément, estimant qu'elles distraient visuellement dans le code.

# Ghostty config (~/.config/ghostty/config)
font-family = "JetBrains Mono"
font-size = 14
adjust-cell-height = 2
font-feature = "calt"
font-feature = "liga"
background-opacity = 0.95
theme = "catppuccin-mocha"
scrollback-limit = 100000
# Shell integration — Ghostty auto-injects on macOS,
# but you may need this on Linux:
# source "$GHOSTTY_RESOURCES_DIR/shell-integration/zsh/ghostty-integration"

L'intégration du shell est la fonctionnalité la plus sous-utilisée des terminaux modernes. Ghostty, Kitty et WezTerm savent détecter les frontières entre commandes, là où la sortie d'une commande se termine et où la suivante commence. Vous pouvez ainsi sauter d'une invite à l'autre, sélectionner la sortie d'une seule commande en un clic et recevoir une notification quand une commande longue se termine. Cela demande un petit ajout à votre configuration de shell, généralement le simple chargement d'un script. Le gain de productivité est disproportionné par rapport à l'effort de mise en place.

# Shell integration for Ghostty in .zshrc
if [[ -n "$GHOSTTY_RESOURCES_DIR" ]]; then
source "$GHOSTTY_RESOURCES_DIR/shell-integration/zsh/ghostty-integration"
fi
# For Kitty, add to .zshrc:
if [[ -n "$KITTY_INSTALLATION_DIR" ]]; then
autoload -Uz -- "$KITTY_INSTALLATION_DIR/shell-integration/zsh/kitty-integration"
kitty-integration
fi

Réalités multiplateformes : macOS, Linux et Windows

Le développement d'émulateurs de terminal fait partie de ces domaines où le support multiplateforme est vraiment difficile, pas seulement fastidieux. Chaque OS a ses propres API GPU (Metal, Vulkan, OpenGL, DirectX), ses propres piles de rendu de polices (CoreText, FreeType, DirectWrite), ses propres systèmes de fenêtrage (Cocoa, X11, Wayland, Win32) et ses propres attentes quant au comportement des applications.

Sous macOS, l'expérience est la meilleure sur tous les plans. Metal est une API propre et moderne, CoreText gère bien le rendu des polices et le système de fenêtrage est cohérent. Les quatre principaux terminaux GPU fonctionnent très bien ici.

Linux est plus fragmenté. La grande division est entre X11 et Wayland : certains terminaux gèrent les deux, d'autres non. La qualité des pilotes GPU varie entre les pilotes propriétaires de NVIDIA, la pile Mesa d'AMD et les processeurs graphiques intégrés d'Intel. Les utilisateurs de gestionnaires de fenêtres en mosaïque attendent souvent un comportement différent de celui des utilisateurs de GNOME ou KDE. Ça fonctionne, mais vous devrez peut-être bricoler.

Windows a fait du chemin. Windows Terminal est une solide option accélérée par GPU dès l'installation. WSL2 et WSLg permettent d'exécuter des terminaux natifs Linux sous Windows avec des performances raisonnables. Alacritty et WezTerm ont un support Windows de premier plan. Ghostty est plus récent sur Windows, mais étend progressivement son support.

Où va la technologie des terminaux

Le rendu GPU est désormais un minimum. La prochaine frontière, c'est ce que les terminaux peuvent faire avec la compréhension sémantique qu'ils possèdent déjà. Un terminal GPU ne se contente pas d'envoyer des pixels : il maintient un modèle structuré de l'écran, indiquant quel caractère se trouve dans quelle cellule, quelles couleurs et attributs sont définis, et où se trouvent les frontières de commandes. Ce modèle est la base de fonctionnalités plus intelligentes.

L'intégration avec les outils d'IA est la direction évidente. Les terminaux sont déjà l'interface principale des assistants de code IA, et il existe une pression pour supporter des sorties plus riches : diffs interactifs, validations en ligne, données structurées qui ne sont pas simplement du texte peint à l'écran. Le terminal évolue discrètement, passant d'une grille de caractères à quelque chose de plus proche d'un moteur de rendu de documents riche, sans abandonner le modèle centré sur le texte qui le rend rapide.

L'accessibilité bénéficie enfin de l'attention qu'elle mérite. Les terminaux GPU peuvent exposer leur modèle sémantique de l'écran aux API d'accessibilité de la plateforme, ce qui est potentiellement mieux que les terminaux historiques qui n'exposent que des pixels bruts. Plusieurs projets en ont fait une priorité en 2026, et les résultats sont prometteurs.

On observe aussi un intérêt croissant pour les extensions de terminal basées sur WASM : un modèle de plugin standardisé qui permettrait à des fonctionnalités créées par la communauté (moteurs de rendu personnalisés, gestionnaires de protocoles, processeurs d'entrée) de tourner en toute sécurité sur différents terminaux. C'est encore tôt, mais l'idée d'un écosystème d'extensions de terminal, comme les extensions de navigateur mais pour la ligne de commande, a un attrait évident.

Le VT100 est sorti il y a presque cinquante ans. L'abstraction de base qu'il a établie, une grille de caractères manipulée par des séquences d'échappement, a démontré une remarquable longévité. Ce qui a changé, ce n'est pas l'abstraction mais l'implémentation : rendu GPU, protocoles modernes, intégration native à la plateforme. Le terminal n'avait pas besoin d'être réinventé. Il fallait le réingénierer. Et ce travail, enfin, est bien engagé.