Nouveaux moteurs de rendu pour GTK
(blog.gtk.org)- L’infrastructure de rendu de GTK est réorganisée autour de ngl pour GL et de vulkan pour Vulkan, avec une architecture unifiée où les deux moteurs sont compilés à partir de la même source
- L’implémentation commune s’appuie sur le flux de l’API Vulkan et abstrait les différences entre GL 3.3+ et GLES 3.0+, ce qui permet de partager la base de l’infrastructure de rendu comme le parcours du graphe de scène et les caches
- Le nouveau moteur privilégie pour l’instant la justesse et la maintenabilité plutôt que la vitesse, tout en améliorant l’anticrénelage, la mise à l’échelle fractionnaire, les dégradés avec un nombre illimité de points d’arrêt de couleur et la prise en charge de dmabuf
- Les développeurs d’applications doivent vérifier l’absence de prise en charge des nœuds glshader, les changements de gestion des positions fractionnaires et les éventuels problèmes de pilotes ; même si cela ressemble à un bug du pilote, il est préférable de le signaler à GTK
- Dans le snapshot GTK 4.13.6, ngl devient la nouvelle valeur par défaut, mais il ne s’agit encore que d’un essai ; en cas de problème majeur, GTK 4.14 pourra revenir à l’ancien moteur gl
Un moteur de rendu unifié pour GL et Vulkan
- GTK ajoute un nouveau moteur de rendu ngl pour GL et un nouveau moteur vulkan pour Vulkan
- Les deux moteurs étant compilés à partir de la même source, ils sont qualifiés de moteur de rendu unifié
- Le modèle d’implémentation suit l’API Vulkan et inclut une couche d’abstraction pour gérer les différences entre GL 3.3+ et GLES 3.0+
- Cette structure permet de mutualiser des fondations qui devaient auparavant être maintenues séparément pour chaque moteur
- parcours du graphe de scène
- gestion des transformations et d’autres états
- caches de textures et de glyphes
- travail de maintenance pour garder les deux moteurs alignés sur les évolutions récentes
Conditions pour une extension vers Metal et DirectX
- La même approche pourrait être étendue à l’avenir à un moteur basé sur Metal sur macOS ou sur DirectX sous Windows
- Vulkan et GL sont avantagés par le fait qu’ils partagent fondamentalement le même langage de shader, GLSL
- Cette condition ne s’applique pas à Metal ni à DirectX, ce qui impose soit d’écrire les shaders en double, soit d’utiliser un outil de conversion comme SPIRV-Cross
- Les contributeurs intéressés par ce travail sont les bienvenus
Méthode d’implémentation et ubershader
- L’ancien moteur GL utilisait un shader simple pour chaque type de rendernode et, pour les contenus complexes, s’appuyait souvent sur un rendu hors écran
- Le moteur unifié dispose lui aussi de shaders par nœud plus puissants, mais utilise également des shaders complexes qui interprètent les données de tampon au lieu de passer par le hors écran
- Dans la programmation de jeux, cette approche est appelée ubershader
- La nouvelle implémentation est moins optimisée que l’ancien moteur GL, mais elle privilégie la justesse et la maintenabilité afin de traiter correctement une plus grande variété d’arbres de rendernode
Qualité de rendu et nouvelles fonctionnalités
-
Anticrénelage
- L’ancien moteur GL pouvait perdre de petits détails assez fins pour tenir entre les limites d’une seule ligne de pixels
- Ce problème pouvait aussi affecter des soulignements comme les mnémoniques
- Le moteur unifié préserve mieux les petits détails et réduit aussi l’effet d’escalier sur les contours des primitives
-
Mise à l’échelle fractionnaire
- L’anticrénelage constitue la base d’une bonne prise en charge de la mise à l’échelle fractionnaire
- Lorsqu’une fenêtre de 1200×800 est mise à l’échelle à 125 %, le moteur unifié utilise un framebuffer de 1500×1000
- Cela implique bien moins de pixels à traiter et une image plus nette que de laisser le compositeur réduire une image de 2400×1600
-
Dégradés arbitraires
- L’ancien moteur GL ne gérait qu’un maximum de 6 points d’arrêt de couleur pour les dégradés linéaires, radiaux et coniques
- Le moteur unifié autorise un nombre illimité de points d’arrêt de couleur
- L’anticrénelage est aussi appliqué aux dégradés afin d’adoucir les lignes sur les bordures nettes
-
dmabuf
- GTK a travaillé depuis l’automne dernier sur la prise en charge de dmabuf et l’offloading graphique
- Le nouveau moteur le prend en charge et étend l’API render_texture pour pouvoir créer un dmabuf lorsqu’une création de texture est demandée
- Cette extension ne concerne pour l’instant que le moteur Vulkan
Points à vérifier pour les développeurs d’applications
-
Nœuds glshader non pris en charge
- Les nœuds glshader étaient utiles dans les démos GTK 4.0, mais restent fortement liés à l’ancien moteur GL
- Ces nœuds reposent sur l’API GLSL exposée par l’ancien moteur
- Le nouveau moteur ne prend pas en charge les nœuds glshader
- La documentation GTK recommande de vérifier cette dépendance avant usage et, en cas d’échec, d’utiliser un shader plus simple ou une voie de repli sans shader
- Depuis GTK 4.0, des fonctions comme les nœuds mask et la prise en charge des textures straight-alpha ont été ajoutées, rendant inutiles de nombreux cas d’usage des nœuds glshader
-
Positions fractionnaires
- L’ancien moteur GL arrondissait les positions, ce qui pouvait masquer les problèmes même si des coordonnées fractionnaires étaient fournies
- Le nouveau moteur place les éléments exactement à la position demandée
- Cette différence peut produire des résultats inattendus ; il faut donc vérifier que les positions sont bien celles voulues
- Il faut notamment faire attention au dessin de style cairo, où une ligne est placée sur une demi-position de pixel pour remplir exactement une ligne de pixels
-
Problèmes de pilotes
- Le nouveau moteur utilise les pilotes graphiques d’une manière nouvelle et différente, ce qui peut faire apparaître des problèmes côté pilote
- Même si le problème ressemble à un souci de pilote, il vaut mieux le signaler à GTK
- Cela aide à évaluer le comportement du nouveau code sur différents pilotes et matériels
État actuel des performances
- Le nouveau moteur n’est pas encore plus rapide que l’ancien
- L’ancien moteur GL est fortement optimisé pour la vitesse, utilise des shaders plus simples et n’effectue pas les calculs nécessaires à des fonctions comme l’anticrénelage
- L’objectif final est de rendre le nouveau moteur plus rapide, mais pour l’instant les principaux progrès portent sur les nouvelles fonctionnalités et la justesse
- Tous les moteurs de rendu actuels basés sur le GPU sont suffisamment rapides pour afficher des applications GTK à 60 fps ou 144 fps
- Dans des benchmarks non scientifiques, le moteur Vulkan se situe à peu près au niveau de l’ancien moteur GL, voire le dépasse dans certains cas
- La raison pour laquelle le nouveau moteur GL est plus lent n’a pas encore été identifiée
Changement de valeur par défaut et exceptions
- Dans le snapshot GTK 4.13.6 tout juste publié, le moteur ngl devient la nouvelle valeur par défaut
- Ce changement est un essai, et il faut des tests plus larges sur plusieurs applications pour vérifier sa préparation à la production
- En cas de problème majeur, GTK 4.14 pourra revenir à l’ancien moteur gl
- Le moteur Vulkan n’est pas encore celui par défaut
- Le port GTK4 de WebKit fonctionne avec GL, mais pas avec Vulkan
- GtkGLArea et GtkMediaStream créent actuellement des textures GL, que le moteur Vulkan ne peut pas importer directement
- Si ces problèmes sont résolus dans un avenir proche, le choix du moteur par défaut sera réexaminé
- Sur du matériel très ancien, l’ancien moteur GL peut rester préférable
- L’ancien moteur GL impose moins d’exigences au GPU
- La variable d’environnement
GSK_RENDERERpermet de forcer le choix du moteur - Exemple :
GSK_RENDERER=gl
Travaux possibles à venir
- Le nouveau moteur pose les bases de fonctionnalités attendues depuis longtemps
- Les pistes envisagées pour la suite incluent notamment :
- une gestion correcte des couleurs, y compris le HDR
- le rendu de tracés sur GPU
- potentiellement le rendu de glyphes
- le rendu hors du thread principal
- des améliorations de performances sur les appareils anciens et moins puissants
- Certains de ces points devraient devenir des priorités à court et moyen terme
- D’autres fonctionnalités sont déjà prévues pour le nouveau moteur, et les utilisateurs peuvent l’essayer eux-mêmes et faire remonter leurs résultats
1 commentaires
Avis sur Hacker News
Il y a longtemps, peut-être vers 2010, il me semble qu’il existait un moteur de rendu HTML expérimental qui affichait des applications GTK dans le navigateur et composait l’UI en HTML+CSS ordinaires
À l’époque, c’était vraiment impressionnant, et c’était sans doute avant Atom, VS Code, Electron, et peut-être même NodeJS
Je ne sais pas si ce moteur de rendu existe encore
https://docs.gtk.org/gtk4/broadway.html
https://www.phoronix.com/news/GTK4-Broadway-Being-Used
Je ne pensais pas que c’était un backend dominant/officiel, mais il existe toujours et a même été porté vers Gtk4
Son comportement se rapproche plutôt d’une approche pur canvas qui jette presque tout ce que fournit le navigateur et reconstruit tout depuis zéro
Les critères pour juger d’un comportement correct sont en général (a) utiliser le défilement du navigateur, (b) utiliser le rendu de texte du navigateur, (c) traiter les liens comme de vrais éléments ; Broadway échoue sur les trois points
Il réimplémente le défilement, rend le texte côté serveur et l’envoie sous forme d’image, et il semble vraiment se bloquer quand on essaie de cliquer sur un lien
En plus, la saisie de texte semble n’utiliser que les événements clavier, donc la composition IME est complètement cassée, et la navigation au clavier est probablement gérée côté GTK plutôt que nativement
Il ne fournit pas non plus d’arbre d’accessibilité significatif
C’est acceptable comme démo technique ou pour un usage personnel en acceptant ses limites, mais inadapté à une distribution publique ; en pratique, ça ressemble davantage à du RDP/VNC avec un peu de DOM
Il faut aussi garder en tête que tout le code s’exécute côté serveur
C’est essentiellement du streaming de données de pixels vers un élément canvas, donc presque la même chose que VNC avec un visualiseur web
https://imgur.com/a/2EDZ2Ti
https://github.com/moondev/gtk3-docker
Mon cas d’usage était d’exécuter un navigateur dans le navigateur, afin d’interagir facilement avec des services Kubernetes clusterip sans port forwarding ni proxy
Un autre exemple sympa consiste à lancer virt-manager, exécuter une VM avec gtk virt-viewer, puis la piloter depuis le navigateur
https://github.com/m-bers/docker-virt-manager
J’aimerais que GTK ne suive pas la tendance consistant à mettre des widgets dans la barre de titre
Certains éléments se déplacent par glisser-déposer et d’autres non, et il reste aussi moins de place pour afficher le nom de l’application et le nom du fichier
Ce reproche ne vise pas seulement GTK
Un redimensionnement fractionnaire précis au pixel près, très bien, youhou !
Maintenant, si Wayland finit par le prendre correctement en charge, on devrait pouvoir avoir une prise en charge HiDPI dans tous les grands environnements de bureau Linux
Il est dit que si une fenêtre de 1200×800 est mise à l’échelle à 125 %, le moteur de rendu unifié utilise un framebuffer de 1500×1000 au lieu de laisser le compositeur réduire une image de 2400×1600
Si je comprends bien, cela veut dire qu’à cause du facteur 125 %, une fenêtre qui, du point de vue des pixels applicatifs, fait 1200×800 doit être dessinée à l’écran en 1500×1000 pixels
Comme OpenGL et Vulkan rendent en virgule flottante, l’idée serait qu’il suffit de dessiner directement dans un buffer pouvant être rendu à l’écran en 1:1 via une transformation de coordonnées
Si c’est bien ça, ça ressemble enfin à une approche de bon sens
Y a-t-il quelqu’un qui comprenne vraiment comment fonctionne un environnement de bureau sous Linux ? Moi, pas vraiment
J’ai juste l’impression que ça devient de plus en plus complexe et bricolé par-dessus l’existant
L’architecture client/serveur était finalement l’exact opposé du modèle de traitement graphique fortement intégré auquel nous sommes arrivés
Au lieu d’abandonner X11 tôt et de limiter les dégâts, les fournisseurs Unix comme le monde open source ont passé bien trop longtemps à essayer de faire de la limonade avec un camion entier de citrons pourris
C’est pour cela que les interfaces graphiques Linux ont pris autant de retard
Apple, qui n’était pas liée à X11 et a adopté un modèle intégré, a pu faire progresser rapidement l’interface graphique Unix, et il est frappant de voir qu’elle conçoit désormais jusqu’à ses propres GPU
Je me demande quel impact aura l’architecture Wayland, et si des applications propres à GNOME finiront vraiment par apparaître
Ce serait bien d’avoir un moteur de rendu de texte ANSI
Pour pouvoir exécuter des programmes GTK dans mon xterm, avec éventuellement un peu de sixel en plus
Une barre latérale, quelques comportements dans la barre de titre, une structure de vue détaillée
Les apps Mac, les apps Windows « modernes » et les apps mobiles se ressemblent aussi
Je me demande si une boîte à outils UX pourrait être entièrement déclarative et sémantique
À haut niveau, on dirait simplement « maître/détail, une vue en liste avec ces champs, quelques actions sont nécessaires », sans préciser de position ni de style, et elle utiliserait automatiquement les widgets système appropriés
Par-dessus, on pourrait ajouter un peu de CSS ou une échappatoire vers des widgets natifs
Presque toutes les apps qui ne sont pas des navigateurs, des éditeurs WYSIWYG ou des lecteurs multimédias semblent entrer dans ce cadre, et le point clé est qu’il serait facile de générer une TUI à partir d’une telle description
https://github.com/fathyb/carbonyl
https://i.imgur.com/pIQ4K7Q.png
S’ils avaient utilisé https://wgpu.rs/, ils auraient eu DirectX et Metal gratuitement :)
Ce travail a vraiment l’air amusant
En lisant la partie sur l’anticrénelage, je me suis demandé si les champs de distance signés, comme dans les moteurs de jeu, ne fonctionneraient pas aussi bien pour le rendu de polices à n’importe quelle échelle
Valve a publié un bon article sur ce sujet
Le code d’UI des moteurs de rendu de jeux, ou le rendu de decals, regorge de techniques élégantes qui pourraient aussi être utiles au code de GUI
Je ne comprends pas pourquoi la dégradation des performances est jugée acceptable
Je fais l’essentiel de mon travail sur du matériel ancien, et ce sont des fonctionnalités que j’aimerais pouvoir désactiver si possible ; il se peut même que mon GPU ne les prenne pas en charge
S’il y a une baisse de performances notable, on peut utiliser
GSK_RENDERER=glMicrosoft, Apple ou Google n’auraient probablement même pas discuté de ce genre de point
Microsoft aurait sans doute dit « oubliez l’ancienne API, voici la nouvelle », Apple « obligatoire à partir de ${WEIRD_NAME} », et Google « vous n’aurez pas cette mise à jour »
Ce qui est décevant, en revanche, c’est que le moteur de rendu Vulkan n’atteigne que des performances à peu près identiques à celles de l’ancien moteur GL
Cela semble indiquer que le problème vient davantage de l’appelant que de l’API 3D elle-même
Il aurait fallu suivre les performances pendant toute l’implémentation et itérer dessus, plutôt que de miser sur une « pureté architecturale », ce qui n’était probablement pas une bonne idée
Je n’ai jamais vu la conversion d’une API de rendu en mode immédiat vers un mode conservé la rendre plus rapide
C’est sans doute possible d’une manière ou d’une autre, mais cela demanderait un travail énorme, et corriger les cas pathologiques nécessiterait aussi des changements côté clients de l’API
D’après mes souvenirs, la plupart utilisent des MacBook coûteux, donc beaucoup de problèmes sont écartés d’un « ça marche sur ma machine »
Par exemple, il existe plusieurs problèmes de rendu des polices qui n’affectent pas les écrans Retina
J’espère que cela ne sonnera pas amer, mais la plupart des bons développeurs de moteurs graphiques ont déjà conçu des renderers avec plusieurs générations d’avance sur les renderers des toolkits GUI open source
Plusieurs d’entre nous pourraient apporter un rendu réellement de nouvelle génération au desktop open source, mais nous travaillons dans des studios de développement de jeux, et c’est ce qui nous fait vivre
Nous n’avons pas le temps de contribuer à la stack open source
Si la communauté pouvait organiser un budget pour rémunérer régulièrement ce type de développeurs, cela changerait beaucoup de choses pour la mise à jour des renderers et des toolkits
Il en va de même pour les autres apps open source
Les graphismes 2D ont très peu de choses en commun avec les moteurs de jeu
En 2D, les entrées sont généralement des courbes de Bézier et d’autres splines, il y a beaucoup d’overdraw, et la gestion de la mémoire VRAM se complique à cause des textures fournies par l’utilisateur
À l’inverse, les moteurs de jeu résolvent des problèmes difficiles sans rapport avec un renderer 2D, comme l’éclairage dynamique, les effets volumétriques ou les environnements dynamiques
J’ai l’impression que les toolkits d’UI de jeux et les frameworks de GUI desktop vivent dans des mondes distincts, avec des attentes différentes
D’après mon expérience professionnelle avec les deux, GTK/Qt gèrent généralement bien, voire très bien, l’intégration au système d’exploitation, les fonctionnalités d’accessibilité, la navigation au clavier et des fonctions comme copier/coller
Les toolkits d’UI de jeux n’ont pas besoin de ces choses et les abandonnent souvent complètement, en se concentrant plutôt sur les performances, les thèmes et l’intégration avec le moteur de jeu
En théorie, on pourrait dire que le renderer est indépendant de ces aspects, mais en pratique ce n’est pas totalement le cas
Quand le budget est limité, les fonctionnalités sur lesquelles on consacre du temps diffèrent aussi
Un renderer extrêmement rapide et précis n’est pas aussi important dans un framework de GUI desktop que dans un toolkit d’UI de jeu
Combien prennent en charge le CMYK et les unités d’impression ?
On ne fait qu’effleurer la surface des choses nécessaires à un renderer GUI mais inutiles pour un moteur de jeu
Je suis très sceptique à l’idée que des développeurs de jeux puissent se réunir et bricoler quelque chose de bien plus rapide que Skia sans sacrifier beaucoup de fonctionnalités
Des personnes qui doivent gagner leur vie, mais qui contribuent autant qu’elles le peuvent en utilisant le logiciel et en apportant parfois du code
Bien sûr, ce serait formidable si la communauté pouvait réunir des fonds, mais ce travail de coordination lui-même ne fait vivre personne
J’aime l’open source/le logiciel libre, je suis reconnaissant qu’il existe et j’y contribue quand je le peux, mais je pense depuis longtemps que c’est une activité de privilégiés
Il faut avoir du temps libre, pouvoir consacrer ce temps libre à quelque chose qui n’améliore pas son niveau de vie, et pouvoir le faire dans la durée
Je travaille dans l’industrie du jeu, et si les renderers 3D sont très bons, je n’ai jamais vu de renderer d’UI 2D que je considérerais comme compétitif
Qu’utilisent-ils pour le rendu des chemins et des motifs ?