Nouveau graphe de scène dans Qt 5.2
Qt 5.2 introduit un nouveau moteur de rendu pour le graphe de scène de Qt Quick.
Lors de la création du graphe de scène il y a trois ans, l'objectif était de tirer parti d'OpenGL et qu'il ait les performances d'un jeu vidéo. Le moteur de rendu livré avec Qt 5.0 est sur la bonne voie pour satisfaire les objectifs initiaux. Pour le contenu opaque, il trie le contenu selon l'état et affiche d'avant en arrière afin de minimiser le surcoût de communication avec le GPU. Dans le dépôt playground/scenegraph, différents moteurs de rendu traitent les primitives similaires par lot afin de réduire le nombre d'appels aux fonctions de rendu (ce qui implicitement réduit le nombre de changements de contexte).
Le nouveau moteur de rendu de Qt 5.2 combine ces deux techniques et essaye de détecter les zones qui ne changent pas dans la scène et les garde dans la mémoire du GPU. Qt 5.2 ajoute aussi le support des textures atlas ce qui était précédemment situé dans playground/scenegraph/customcontext. Cela participe grandement au traitement par lot du contenu texturé. Avec ce nouveau moteur de rendu, Qt 5.2 satisfait aux objectifs initiaux plus que jamais.
Une nouvelle section de la documentation explique les détails du moteur de rendu pour les plus curieux. Une connaissance approfondie des moteurs de rendu n'est pas nécessaire, mais le document sera néanmoins intéressant pour beaucoup d'entre vous.
Quelques chiffres pour continuer :
Trois tests de performance sont disponibles dans les dépôts :
- « Extreme Table » contient une grande table avec un peu de contenu animé au-dessus. Cet exemple met en avant les bénéfices de la rétention des données sur le GPU ;
- « List Bench » affiche un grand nombre de listes déroulantes avec icônes, en alternant la couleur de fond et avec deux textes par cellule ;
- « Flying Icons » contient plus de 3000 images animées, chacune possédant sa propre animation.
Sont aussi inclus la première page de la galerie d'exemples des contrôles Qt Quick ainsi que Samegame. Samegame est joué en mode « Zen » et les clics sont effectués sur le rythme de « Where Eagles Dare » d'Iron Maiden.
http://tcuvelier.developpez.com/news...aph/traces.png
La mesure du nombre d'appels à OpenGL pour le rendu ainsi que du trafic a été réalisée grâce à apitrace, un outil incroyable pour déboguer avec OpenGL. Comme vous pouvez le voir au niveau des nombres en vert, le nombre d'appels aux fonction d'OpenGL a été drastiquement réduit, notamment dans les cas où il y avait de nombreuses occurrences du même contenu, c'est-à-dire des listes, des tables ou des grilles.
Le trafic par image a lui aussi été grandement amélioré. Les meilleurs exemples sont « ExtremeTable » et « ListBench », qui ont été échantillonnés avec une image sur laquelle aucun nouveau délégué n'était ajouté ou supprimé. Remarquez ici que l'exemple « ListBench » apparaît avec un trafic de 0 par image. Il y a bien sûr un peu de trafic, les appels aux fonctions de rendu elles-mêmes et d'autres appels fonctionnels, mais aucune donnée contenant des sommets ou des textures, tout ce que l'outil est capable de mesurer. « FlyingIcons » change le contenu entier de la scène à chaque nouvelle image, il est ainsi impossible d'effectuer la moindre rétention sur le GPU. La galerie des contrôles est principalement statique, mais contient des barres de progression animées qui nécessitent une nouvelle texture à chaque image. Cela constitue la majorité du trafic d'environ vingt kilooctets. Samegame apparaît comme gourmand, cet qui est principalement dû à son usage intensif des particules. La leçon du jour est que, si vous êtes limité au niveau de la mémoire, vous devriez limiter le nombre de particules de la scène.
Ce sont des nombres théoriques mais ils donnent une idée des capacités du nouveau moteur de rendu. Regardons maintenant les nombres provenant des cas réels. Les tableaux qui suivent montrent les cas où le nouveau moteur de rendu a le plus d'impact. Le tableau complet des mesures se trouve à la fin de l'article.
Notez que ces tests de performance sont exécutés sans utiliser le nouveau moteur QML basé sur V4. Ce nouveau moteur V4 affecte lui aussi les performances et il était plus pertinent de s'intéresser uniquement aux améliorations uniquement dues au nouveau moteur de rendu.
http://tcuvelier.developpez.com/news.../listbench.png
Le temps de rendu est mesuré avec la synchronisation verticale activée, mais sans compter le swap. Quand le MacBook passe 16ms lors de la phase de rendu, il est en fait ralenti lors des commandes OpenGL. En regardant les indicateurs d'OS X, on s'aperçoit que le pilote passe beaucoup de temps à attendre la synchronisation, ce qui signifie que le pipeline est obstrué. Avec le moteur de rendu de Qt 5.2, cette attente lors de la synchronisation n'existe plus. C'est une très bonne nouvelle étant donné que les contenus de type liste et assimilés sont très courants dans les interfaces graphiques.
http://tcuvelier.developpez.com/news...raph/table.png
Au niveau du MacBook avec le processeur graphique intégré et la Nexus, le nouveau moteur de rendu réduit drastiquement le temps passé à exécuter les appels à OpenGL. Un bogue connu empêche de réduire le temps de rendu de l'exemple « Extreme Table » à zéro.
http://tcuvelier.developpez.com/news...aph/flying.png
L'exemple « FlyingIcons » met le CPU à rude épreuve, à cause des 3 000 animations tournant en parallèle. Vous voyez néanmoins une nette amélioration quant à la durée passée dans le moteur de rendu.
Voici les autres résultats :
http://tcuvelier.developpez.com/news...h/numbers1.png
Les résultats obtenus concordent avec les estimations théoriques du départ. Lors de l'affichage de contenu récurrent, comme les listes ou les grilles, Qt 5.2 est une vraie amélioration vis-à-vis de Qt 5.1. Pour les autres cas typiques, les améliorations ne sont pas fulgurantes, mais au moins ne les font pas empirer.
Source : http://blog.qt.digia.com/blog/2013/0...raph-renderer/
