Rendre du texte net sur GPU

• Une nouvelle technique de rendu vectoriel en temps réel est proposée pour résoudre les problèmes de qualité du rendu de texte, en particulier les limites des approches basées sur les SDF (champs de distance)
• En envoyant directement au GPU les glyphes sous forme de courbes vectorielles afin de les rastériser en temps réel, elle permet d’obtenir une résolution illimitée tout en réduisant l’usage mémoire
• L’utilisation d’un atlas de textures et de l’accumulation temporelle permet d’atteindre une qualité d’anticrénelage élevée ainsi qu’un cache efficace
• La méthode peut être adaptée à diverses structures de sous-pixels (par exemple OLED, LCD, etc.), pour produire un résultat lisse et net sans problème de franges colorées
• Elle propose une approche simple mais très extensible pour le rendu de polices haute qualité dans le texte en temps réel, les interfaces UI, les jeux, etc.

---

Introduction : les défis du rendu de texte

• Le rendu de texte en temps réel pose de nombreux problèmes : aliasing (effet d’escalier), textures volumineuses, temps de build, zoom, défilement fluide, etc.
• L’approche Multi-Channel Signed Distance Fields (SDF), très utilisée jusqu’ici, présentait des limites en matière de qualité et de flexibilité
• Les structures de sous-pixels non standard des moniteurs OLED récents, ainsi que les problèmes de franges colorées, ont conduit au développement d’une nouvelle approche intégrant aussi l’anticrénelage sous-pixel

Limites des approches SDF existantes

Qualité

• Avec les SDF, les polices comportant beaucoup de détails fins ou de traits minces subissent une baisse de qualité et des pertes d’information
• Sans augmentation de la résolution, certains glyphes conservent des artefacts

Taille de l’atlas

• Les SDF sont générés hors ligne puis stockés dans un atlas, mais avec un grand nombre de glyphes ou des polices CJK (chinois, japonais, coréen), la taille devient pratiquement ingérable
• L’utilisation simultanée de plusieurs polices augmente fortement la consommation mémoire et la pression sur la bande passante de streaming

Flexibilité et simplicité

• Le passage par l’étape intermédiaire des SDF complexifie l’ensemble du flux, depuis les données source jusqu’au résultat final
• Cela limite fortement l’utilisation ou l’édition directe en temps réel d’images vectorielles dynamiques

Nouvelle approche : rastérisation en temps réel de courbes vectorielles

• Au lieu de pré-générer des textures, les données de courbes vectorielles des glyphes réellement visibles à l’écran (courbes de Bézier, etc.) sont envoyées directement au GPU puis rastérisées sur place
• Seuls les glyphes nécessaires sont placés dans l’atlas de textures, puis conservés ou libérés selon leur fréquence d’usage
• Tant qu’un glyphe reste affiché, l’accumulation d’échantillons dans le temps (temporal accumulation) permet d’obtenir un résultat anticrénelé très haute qualité et plus doux
• Comme le traitement reste toujours basé sur le vectoriel, le rendu demeure net sans limitation de résolution

Traitement des données de courbes des polices

• Des bibliothèques open source comme FreeType permettent de lire divers formats de police et d’extraire les informations de courbes des glyphes
• Les glyphes sont analysés sous forme de lignes et de courbes de Bézier quadratiques/cubiques, puis toutes les courbes sont converties en courbes de Bézier quadratiques afin de simplifier le traitement dans les shaders GPU
  • Les lignes sont converties en courbes quadratiques par ajout d’un point de contrôle intermédiaire
  • Les courbes cubiques sont transformées en deux courbes quadratiques subdivisées

Calcul de la couverture (remplissage à l’intérieur du pixel)

• Pour chaque pixel, on calcule les intersections entre les courbes et un rayon horizontal, puis on détermine l’intérieur/l’extérieur via le winding number (nombre cumulé d’intersections)
• Des centaines d’échantillons (n accumulations d’échantillons) sont additionnés, et certaines petites erreurs n’ont pratiquement aucun effet sur le résultat final
• Une technique de placement de points d’échantillonnage (séquence quasi aléatoire) permet d’accumuler les résultats à des positions variées à chaque frame

Optimisation de l’accès aux courbes

• Les glyphes sont découpés en bandes horizontales, et seules les courbes pertinentes pour chaque bande sont testées, afin de réduire la quantité de calcul
• La répartition des threads et l’itération par bande maximisent l’efficacité des traitements massifs sur GPU

Empaquetage et gestion de l’atlas

• Chaque image de glyphe est allouée puis gérée dans l’atlas (texture partagée)
  • Si le glyphe est absent, un nouvel espace est alloué puis rastérisé ; s’il est déjà présent, il est réutilisé
  • À noter que même pour un même glyphe, des versions différentes peuvent être nécessaires selon la position sous-pixel et la taille
• Un Z-Order Packing (code Morton, etc.) permet un empaquetage efficace entre un bitmap 1D et un espace 2D
  • L’approche peut être adaptée avec souplesse selon la structure des langues, par exemple orientation verticale pour les langues latines, horizontale pour l’arabe, etc.
• Lorsqu’un glyphe n’est plus nécessaire, l’espace qu’il occupait dans l’atlas peut être réalloué

Accumulation temporelle

• Grâce au cache de glyphes et à l’accumulation d’échantillons, il est possible d’obtenir rapidement des échantillons de haute qualité juste après l’affichage, puis d’affiner progressivement le rendu dans les frames suivantes
  • La première frame utilise 8 échantillons/pixel, puis le nombre diminue progressivement, avec un maximum de 512 accumulations
• La méthode concilie affichage fluide des glyphes et optimisation des ressources

Anticrénelage sous-pixel et prévention des franges colorées

• Le rendu alloue la zone de calcul au niveau des sous-pixels (en considérant chaque composant comme RGB comme un échantillon), ce qui augmente la résolution horizontale effective
  • Prise en charge de différentes dispositions, notamment la structure standard des LCD ainsi que les arrangements OLED/WOLED
  • Permet d’obtenir un effet lisse sans franges colorées
• En disposant les échantillons de sous-pixels avec chevauchement (overlapping), il est aussi possible de refléter l’effet réel de mélange lumineux du moniteur
• Un rendu naturel et net est possible même sans frontières de pixels ni hinting

Importance d’une approche adaptée à la structure de sous-pixels de chaque écran

• Si les informations sur l’agencement des sous-pixels du moniteur peuvent être récupérées par logiciel, un rendu bien plus précis devient possible
• L’article souligne qu’il s’agit moins d’une limite matérielle que d’un problème de traitement logiciel

Conclusion et perspectives d’usage

• Un bon rendu de texte a un impact important sur l’utilisabilité globale et la qualité d’un service
• En particulier dans les UI et les jeux, une représentation typographique de haute qualité peut faire une vraie différence dans l’expérience produit
• Cette architecture concrétise les principes de simplicité, extensibilité, haute qualité et flexibilité
• Avec une implémentation open source et la prise en charge de diverses structures de sous-pixels, elle est très adaptée à une utilisation industrielle et en production

---

[GN⁺]

Commentaires Hacker News

• L’auteur du billet dit qu’il ne s’attendait pas à ce que son texte fasse autant parler de lui, et remercie toutes les personnes ayant participé à cette discussion intéressante
• Question sur la raison pour laquelle le point du "j" en italique disparaissait dans la première vidéo
• Avis selon lequel le rendu de police en sous-pixels est très important pour la lisibilité. Mais, comme l’auteur le souligne, c’est dommage que les standards d’affichage actuels ne permettent pas d’obtenir une spécification précise de l’agencement des pixels
• Certains estiment que cela n’est nécessaire que sur les écrans à définition standard. En réalité, ce n’est pas indispensable, plutôt un plus appréciable. Les écrans de niveau Retina étant désormais généralisés, on se trouve dans un contexte où le rendu en sous-pixels n’est plus vraiment nécessaire. Ce serait davantage une innovation provisoire apparue à l’époque des LCD, et aujourd’hui un peu dépassée. Les effets secondaires sont assez nombreux, comme la dépendance de la disposition des sous-pixels dans les captures d’écran ou l’impossibilité d’agrandir un bitmap. Ce serait d’ailleurs pour cela qu’Apple a complètement supprimé cette méthode de macOS
• Remarque selon laquelle des standards comme DisplayID ont justement été conçus pour fournir ce type d’information sur l’agencement. Le problème serait surtout que les fabricants l’implémentent mal, ou que ces données ne soient pas stockées dans les bases. Pour les modèles d’écrans populaires, on pourrait pourtant enregistrer et exploiter ces informations dans une base de données matérielle. Voir le wiki DisplayID
• Regret qu’on connaisse depuis des décennies la diversité des structures de sous-pixels sans avoir vraiment traité le sujet, tout en saluant la clarté de l’article d’origine. Partage également d’une page d’exemples surnommée le « zoo des sous-pixels » : subpixel zoo
• Certains jugent que parler de « tragédie » est excessif. Il suffirait que chaque OS propose un réglage fin par écran, comme l’ancien tuner ClearType de Windows. Il faudrait aussi que le système mémorise les préférences utilisateur au cas où un moniteur remonte de mauvaises informations
• Position selon laquelle le rendu en sous-pixels n’est pas indispensable dans la plupart des langues. Des polices bitmap sans anticrénelage ou des polices vectorielles avec hinting restent déjà faciles à lire. En revanche, c’est plus important pour des langues utilisant des caractères complexes, comme le chinois ou le japonais
• À propos de GTK4, qui est passé à un rendu centré sur le GPU en abandonnant le rendu RGB en sous-pixels, certains pensent que ce choix était lié aux technologies GPU. Mais puisque l’article montre que c’est possible sur GPU, on se demande s’il n’y avait pas d’autres raisons, d’autres inconvénients, ou des difficultés d’intégration dans la stack
• Mention de la possibilité que Cosmic Text (Cosmic DE), via Swash, prenne en charge le rendu en sous-pixels sur GPU
• Si vous vous intéressez à la manière d’implémenter SDF et MSDF dans WebGL/WebGPU, recommandation d’un tutoriel écrit par l’un des commentateurs : lien du tutoriel
• Quelqu’un indique s’intéresser à WebGPU (WGPU) implémenté en Rust. Il a trouvé ce tutoriel plutôt avancé et dit avoir appris efficacement en adaptant les exemples JS vers Rust
• Un autre dit beaucoup aimer le format du site et vouloir créer lui aussi des tutoriels GPU de cette manière. Il demande s’il s’agit d’un modèle particulier ou d’une partie d’un cours
• Partage d’information sur la bibliothèque Slug, un middleware commercial qui implémente un rastériseur de glyphes sur GPU : Slug Library
• Le site de Slug publie des détails assez poussés sur l’algorithme, ce qui paraît intéressant. Quelqu’un se demande s’il existe des brevets. Une version open source en wgpu, utilisant cosmic-text pour le parsing et la mise en page des polices, serait amusante à faire, mais il y a la crainte d’être ensuite attaqué en justice par Slug
• Pour les personnes peu familières du sujet, un commentaire résume l’histoire et l’état actuel du rendu de texte SDF. Valve a présenté en 2007 une architecture basée sur SDF, puis Glyphy en 2012 (Behdad Esfahbod) a proposé une implémentation SDF sur GPU, mais les OS grand public et les navigateurs web restent encore globalement sur une approche de type TrueType héritée des années 1990. Cette méthode est petite et légère, mais elle ne prend pas bien en charge l’alignement sous-pixel ni des mises en page arbitraires, et elle impose aussi de fortes limites au zoom du texte ou aux transformations 3D. Si l’évolution est aussi lente, c’est sans doute parce que le gain ne compense pas assez le risque, et parce que la collaboration GPU/CPU est difficile non seulement pour le rendu, mais aussi pour des traitements complexes de mise en page comme le retour à la ligne
• Réponse rappelant que les tâches de mise en page textuelle, comme le retour à la ligne, sont en pratique presque indépendantes du rendu lui-même
• Présentation de Pathfinder de Servo comme exemple ayant déjà implémenté un rendu de texte GPU bien plus performant via des compute shaders GPU
• Lien vers un article sur la méthode de rendu de texte GPU de WebKit. Même aujourd’hui, une partie de la chaîne, de la chaîne de caractères au bitmap, peut être traitée sur GPU, mais on souligne que l’anticrénelage en sous-pixels attendu est absent des démonstrations de promotion GPU
• Il est aussi rappelé que non seulement Windows, mais aussi Chrome et Firefox, avaient déjà une accélération GPU du rendu avec anticrénelage en sous-pixels depuis plusieurs années. L’idée que les techniques récentes ne seraient pas utilisées est donc trompeuse
• Commentaire remerciant pour ce résumé clair et concis
• Si l’on veut un rendu en sous-pixels, il faut partir du principe qu’il faut connaître précisément la grille de sous-pixels de l’écran. Certains estiment que la seule UX raisonnable consiste à demander un réglage spécifique pour chaque moniteur. L’OS doit aussi gérer des cas comme la rotation de l’écran
• D’autres jugent, comme l’auteur, que l’idéal serait que l’écran communique directement au système sa structure de sous-pixels
• Évaluation très positive du résultat obtenu, accompagnée de l’idée que l’anticrénelage en sous-pixels avait un avantage net à l’époque des écrans LCD du début des années 2000, mais qu’il est devenu presque inutile à l’ère des écrans Retina haute définition. Parmi les inconvénients cités : applicable seulement sur des arrière-plans opaques, impossible à post-traiter (redimensionnement, miroir, flou, etc.), et captures d’écran qui paraissent étranges sur d’autres appareils
• En réponse, quelqu’un note que supprimer l’AA en sous-pixels simplifie les choses, mais rappelle qu’il existe encore beaucoup d’utilisateurs desktop sur des écrans basse définition 96dpi ou 1366x768, chiffres à l’appui via l’enquête matérielle de Firefox : données
• Une autre réponse ajoute qu’en tant qu’utilisateur d’écrans haute définition, ignorer les utilisateurs d’écrans basse définition serait irresponsable
• Inquiétude aussi sur le fait que, même avec un protocole décrivant l’agencement des sous-pixels, certains fabricants l’implémenteraient mal, ce qui provoquerait des problèmes de rendu difficiles à comprendre pour le grand public
• En voyant l’écriture cursive, première réaction très franche de quelqu’un : « Qui a bien pu penser qu’une telle cursive était une bonne idée ? »
• Réponse expliquant que cela plaisait sans doute aux gens qui écrivaient à la main, en particulier à l’époque des plumes et des stylos-plume
• Explication selon laquelle les personnes écrivant beaucoup de lettres utilisaient la cursive, et que son usage a diminué avec l’arrivée d’Internet et des appels longue distance gratuits
• Question demandant où trouver le lien vers le code