GTK (anciennement GIMP ToolKit et GTK+) est un ensemble de bibliothèques logicielles multiplateforme libre et gratuite pour la création d'interfaces utilisateur graphiques (GUI). Développée originellement pour les besoins du logiciel de traitement d'images GIMP, GTK est soumis à la licence GNU Lesser General Public License, ce qui permet aux logiciels libres et propriétaires de l'utiliser dans de nombreux projets. GTK est notamment l'une des boîtes à outils les plus populaires pour les systèmes de fenêtrage Wayland et X11.
Récemment, GTK a gagné non pas un, mais deux nouveaux moteurs de rendu : un pour GL et un pour Vulkan. Appelés "ngl" et "vulkan", ils sont construits à partir des mêmes sources, c'est pourquoi ils sont également appelés des moteurs de rendu "unifiés".
Découvrez ce qu'ils ont de si excitant.
Une source unique
Comme cela a déjà été mentionné, les deux moteurs de rendu sont construits à partir de la même source. Ils ont été modélisés pour suivre les API Vulkan, avec quelques abstractions pour couvrir les différences entre Vulkan et GL (plus spécifiquement, GL 3.3+ et GLES 3.0+). Cela permet de partager une grande partie de l'infrastructure pour parcourir le graphe de scène, maintenir les transformations et autres états, mettre en cache les textures et les glyphes, et facilitera la mise à jour et le maintien à niveau des deux moteurs de rendu.
Cette approche unifiée pourrait-elle être étendue, pour couvrir un moteur de rendu basé sur Metal sur macOS ou un moteur de rendu basé sur DirectX sur Windows ? C'est possible. L'avantage de la combinaison Vulkan/GL est qu'ils partagent fondamentalement le même langage de shader (GLSL, avec quelques variations). Ce n'est pas le cas pour Metal ou DirectX. Pour ces plateformes, il faut soit dupliquer les shaders, soit utiliser un outil de traduction comme SPIRV-Cross.
Détails de l'implémentation
L'ancien moteur de rendu GL utilise des shaders simples pour chaque type de nœud de rendu et a souvent recours au rendu hors écran pour les contenus plus complexes. Les moteurs de rendu unifiés ont également des shaders par nœud (plus performants), mais au lieu de s'appuyer sur les écrans extérieurs, ils utiliseront également un shader complexe qui interprète les données à partir d'un tampon. Dans la programmation des jeux, cette approche est connue sous le nom d'ubershader.
L'implémentation du moteur de rendu unifié est moins optimisée que l'ancien moteur de rendu GL et a été écrite en mettant l'accent sur la correction et la maintenabilité. Par conséquent, elle peut gérer correctement des arbres de nœuds de rendu beaucoup plus variés.
Voici un exemple anodin :
Code : | Sélectionner tout |
1 2 3 4 5 6 7 | repeat { bounds: 0 0 50 50; child: border { outline: 0 0 4.3 4.3; widths: 1.3; } } |
Nouvelles capacités
Tout ce travail n'aurait pas été réalisé s'il n'y avait pas eu des avantages tangibles. Bien sûr, il y a de nouvelles fonctionnalités et capacités. Voyons-en quelques-unes :
L'anticrénelage. L'un des gros problèmes de l'ancien moteur de rendu GL est qu'il perd les détails les plus fins. Si quelque chose est suffisamment petit pour se trouver entre les limites d'une seule ligne de pixels, il disparaîtra tout simplement. Cela peut notamment affecter les soulignés, tels que les mnémoniques. Les moteurs de rendu unifiés gèrent mieux ces cas, en effectuant un anti-crénelage. Cela permet non seulement de préserver les détails fins, mais aussi d'éviter les contours irréguliers des primitives.
Échelle fractionnaire. L'anticrénelage est également la base qui vous permet de gérer correctement les échelles fractionnaires. Si votre fenêtre 1200 × 800 est réglée pour être mise à l'échelle à 125 %, avec les moteurs de rendu unifiés, un framebuffer de taille 1500 × 1000 sera utilisé, au lieu de laisser le compositeur réduire l'échelle d'une image 2400 × 1600. Beaucoup moins de pixels, et une image plus nette.
Dégradés arbitraires. L'ancien moteur de rendu GL gère les dégradés linéaires, radiaux et coniques avec jusqu'à 6 arrêts de couleur. Les rendus unifiés permettent un nombre illimité d'arrêts de couleur. Les nouveaux moteurs de rendu appliquent également un anticrénelage aux dégradés, de sorte que les bords tranchants présentent des lignes lisses.
Dmabufs. Pour faire un bref détour par les nouveaux moteurs de rendu, un travail a été effectué l'automne dernier sur la prise en charge des dmabuf et le déchargement graphique. Les nouveaux moteurs de rendu supportent cela et l'étendent pour créer des dmabufs lorsqu'on leur demande de produire une texture via l'api render_texture (actuellement, seulement le moteur de rendu Vulkan).
Des arêtes vives ?
Comme c'est souvent le cas, les nouvelles capacités s'accompagnent potentiellement de nouveaux problèmes. Voici quelques éléments dont il faut tenir compte en tant que développeur d'applications :
Plus de nœuds glshader. Oui, ils ont permis de faire des démonstrations fantaisistes pour la version 4.0, mais ils sont très liés à l'ancien moteur de rendu GL, puisqu'ils font des suppositions sur l'api GLSL exposée par ce moteur de rendu. Par conséquent, les nouveaux moteurs de rendu ne les supportent pas.
Vous avez été prévenu dans la documentation :
En cas de problème, cette fonction renvoie FALSE et signale une erreur. Il est conseillé d'utiliser cette fonction avant de se fier au shader pour le rendu et d'utiliser une solution de repli avec un shader plus simple ou sans shader en cas d'échec.
Heureusement, de nombreuses utilisations du nœud glshader ne sont plus nécessaires, car GTK a acquis de nouvelles fonctionnalités depuis la version 4.0, telles que les nœuds de masque et la prise en charge des textures straight-alpha.
Positions fractionnaires. L'ancien moteur de rendu GL arrondit les choses, vous pouvez donc vous en sortir en lui donnant des positions fractionnaires. Les nouveaux moteurs de rendu placeront les choses là où vous le leur indiquerez. Cela peut parfois avoir des conséquences inattendues, il convient donc d'être vigilant et de s'assurer que vos positions sont bien celles qu'elles devraient être.
En particulier, faites attention aux dessins de type Cairo, où vous placez des lignes à des positions d'un demi-pixel afin qu'elles remplissent une rangée de pixels avec précision.
Problèmes de pilotes. Les nouveaux moteurs de rendu utilisent les pilotes graphiques d'une manière nouvelle et différente, ce qui peut entraîner des problèmes de ce côté.
Mais sont-ils plus rapides ?
Non, les nouveaux moteurs de rendu ne sont pas (encore) plus rapides.
L'ancien moteur de rendu GL est fortement optimisé pour la vitesse. Il utilise également des shaders beaucoup plus simples et ne fait pas les calculs nécessaires pour des fonctions telles que l'anticrénelage. À terme, il est prévu de rendre les nouveaux moteurs de rendu plus rapides, mais les nouvelles fonctionnalités et l'exactitude des calculs les rendent très intéressants, même avant que cet objectif ne soit atteint. Tous les moteurs de rendu basés sur le GPU sont plus que suffisamment rapides pour rendre les applications GTK d'aujourd'hui à 60 ou 144 fps.
Ceci étant dit, le moteur de rendu Vulkan est proche d'égaler et de surpasser l'ancien moteur de rendu GL dans certains benchmarks non scientifiques. Le nouveau moteur de rendu GL est plus lent pour une raison qui reste à déterminer.
Nouvelles valeurs par défaut
Dans le snapshot 4.13.6 qui vient d'être publié, le moteur de rendu ngl est devenu la nouvelle valeur par défaut. Il s'agit d'un ballon d'essai - les moteurs de rendu doivent être testés plus largement avec différentes applications afin de vérifier qu'ils sont prêts pour la production. Si des problèmes importants apparaissent, il sera possible de revenir au moteur de rendu gl pour la version 4.14.
Il a été décidé de ne pas faire du moteur de rendu Vulkan le moteur par défaut, car il est en retard par rapport aux moteurs de rendu GL sur certains aspects de l'intégration des applications : le port webkit GTK4 fonctionne avec GL, pas avec Vulkan, et GtkGLArea et GtkMediaStream produisent tous deux des textures GL que le moteur de rendu Vulkan ne peut pas importer directement. Tous ces problèmes seront, espérons-le, résolus dans un avenir assez proche, et la décision concernant le moteur de rendu par défaut sera alors réexaminée.
Si vous utilisez GTK sur du matériel très ancien, il est préférable d'utiliser l'ancien moteur de rendu GL, car il sollicite moins le GPU. Vous pouvez modifier la sélection du moteur de rendu en utilisant la variable d'environnement GSK_RENDERER :
Code : | Sélectionner tout |
GSK_RENDERER=gl
Projets futurs et possibilités
Les nouveaux moteurs de rendu sont une bonne base pour implémenter des choses souhaitées depuis longtemps, telles que :
- La gestion correcte des couleurs (y compris HDR)
- Le rendu des paths sur le GPU
- La possibilité d'inclure le rendu des glyphes
- Le rendu hors du thread principal
- Les performances (sur les appareils anciens et moins puissants)
Certains de ces points feront l'objet de futurs travaux dans un avenir proche et à moyen terme.
Résumé
Les nouveaux moteurs de rendu offrent des fonctionnalités intéressantes, et d'autres sont à venir.
N'hésitez pas à les essayer et à faire savoir ce qui fonctionne et ce qui ne fonctionne pas pour vous.
Source : "New renderers for GTK" (GTK)
Et vous ?
Quel est votre avis sur le sujet ?
Que pensez-vous des nouvelles fonctionnalités apportées par ces nouveaux moteurs de rendu, trouvez-vous qu'elles sont intéressantes et utiles ?
Voir aussi :
Sortie de GTK 4.2, le framework de développement d'interfaces graphiques propose un moteur de rendu accéléré matériellement pour toutes les plateformes
GTK 4.0 est disponible. La boîte à outils pour réaliser des interfaces graphiques apporte des améliorations dans le transfert des données et d'une prise en charge intégrée de la lecture multimédia