Nouveaux renderers pour GTK

Nouveaux renderers pour GTK

• Deux nouveaux renderers pour GL et Vulkan ont été ajoutés à GTK.
• Ils reprennent les noms existants, ngl et vulkan.
• Ils sont construits à partir de la même source et sont aussi appelés renderers « unifiés ».

Source unique

• Les deux renderers sont construits à partir de la même source et conçus selon un modèle conforme à l’API Vulkan.
• Ils incluent des abstractions pour couvrir les différences entre Vulkan et GL.
• Cela permet de partager l’infrastructure, comme le parcours du graphe de scène, la conservation des transformations, ainsi que les caches de textures et de glyphes.
• Une extension vers un renderer basé sur Metal sur macOS ou sur DirectX sous Windows est possible.

Détails d’implémentation

• L’ancien renderer GL utilise des shaders simples et s’appuie sur le rendu hors écran pour les contenus complexes.
• Le renderer unifié dispose de shaders par nœud et utilise, au lieu du hors écran, des shaders plus complexes qui interprètent les données dans des buffers.
• Le renderer unifié est moins optimisé, mais il met l’accent sur la précision et la maintenance, ce qui lui permet de traiter correctement une plus grande variété d’arbres de nœuds de rendu.

Nouvelles fonctionnalités

• Anticrénelage : l’ancien renderer GL avait tendance à perdre des détails, ce que le renderer unifié améliore grâce à l’anticrénelage.
• Mise à l’échelle fractionnaire : le renderer unifié peut gérer correctement les échelles fractionnaires.
• Dégradés arbitraires : le renderer unifié peut gérer des dégradés avec un nombre illimité de points d’arrêt de couleur.
• Dmabufs : le renderer Vulkan peut créer des dmabufs lors de la création de textures via l’API render_texture.

Points à noter

• Les nœuds glshader ne sont plus pris en charge.
• Positions fractionnaires : le nouveau renderer place les objets à leur position exacte.
• Problèmes de pilotes : le nouveau renderer utilise les pilotes graphiques d’une manière nouvelle et différente, ce qui peut provoquer des problèmes.

Est-ce plus rapide ?

• Pour l’instant, le nouveau renderer n’est pas plus rapide.
• L’ancien renderer GL est optimisé pour la vitesse, tandis que le nouveau renderer apporte de nouvelles fonctionnalités et une meilleure précision.
• Le renderer Vulkan affiche, dans des benchmarks non officiels, des performances comparables à celles de l’ancien renderer GL.

Nouvelle valeur par défaut

• Dans le snapshot 4.13.6 récemment publié, le renderer ngl a été défini comme nouvelle option par défaut.
• Il s’agit d’une mesure expérimentale, et il est possible de revenir à l’ancien renderer GL en cas de problème.

Plans futurs et possibilités

• Le nouveau renderer constitue une bonne base pour mettre en œuvre une gestion correcte des couleurs, y compris le HDR, le path rendering sur GPU, le rendu hors du thread principal, ainsi que des améliorations de performances.

Résumé

• Le nouveau renderer propose des fonctionnalités intéressantes, et d’autres doivent encore être ajoutées.
• Il est demandé d’essayer le nouveau renderer et de faire des retours sur son fonctionnement.

Opinion de GN⁺

• Le nouveau renderer représente une avancée importante en offrant aux développeurs des options de rendu plus précises et plus variées.
• L’approche unifiée entre Vulkan et GL a le potentiel d’améliorer la compatibilité du rendu sur diverses plateformes à l’avenir.
• Ces avancées techniques contribueront à améliorer l’expérience utilisateur et à renforcer la qualité visuelle des applications.

[GN⁺]

Commentaires Hacker News

• Vers 2010, il existait un moteur de rendu HTML expérimental capable d’implémenter l’interface d’applications GTK dans le navigateur en utilisant uniquement HTML et CSS. À l’époque, c’était très impressionnant, car c’était avant l’arrivée d’Atom, de VS Code, d’Electron et probablement de NodeJS. On ne sait pas si ce moteur de rendu HTML existe encore aujourd’hui.
• Regret que GTK suive la tendance consistant à autoriser des widgets dans la barre de titre. Certains peuvent être déplacés et d’autres non, ce qui réduit l’espace alloué à l’application et au nom du fichier. Ce problème ne se limite pas à GTK.
• Manque de compréhension de la façon dont fonctionnent les environnements de bureau sous Linux. Ils donnent l’impression de devenir de plus en plus complexes et chargés.
• Enthousiasme pour le fractional scaling précis au pixel près.
• Mention que l’utilisation de wgpu.rs permet d’obtenir gratuitement DirectX et Metal.
• Intérêt pour un moteur de rendu de texte ANSI, qui permettrait d’exécuter des programmes GTK dans xterm. Une prise en charge optionnelle de sixel pourrait aussi être ajoutée.
• Interrogation sur les raisons pour lesquelles les baisses de performances sont considérées comme acceptables. La plupart des calculs sont effectués sur du matériel ancien, et ces fonctionnalités peuvent être désactivées ou ne pas être prises en charge par le GPU.
• Le travail sur GTK semble amusant et intéressant. Mention de l’anticrénelage et enthousiasme quant à l’application possible de la technique des signed distance fields, utilisée pour le rendu des polices dans les moteurs de jeu. Diverses techniques employées dans les moteurs de rendu de jeux pourraient aussi être utiles pour le code d’interface graphique.
• De nombreux développeurs de moteurs graphiques ont créé des moteurs de rendu ayant plusieurs générations d’avance sur ceux des toolkits GUI open source, mais la plupart travaillent dans des entreprises de jeux vidéo et n’ont pas le temps de contribuer à la stack open source. Si la communauté pouvait organiser un budget récurrent pour rémunérer ces développeurs, le bureau open source pourrait bénéficier d’importantes mises à jour du rendu et des toolkits.
• Un commentaire spécifique a été signalé et son contenu a été masqué.