I. L'article original▲
Qt Labs est un site géré par les développeurs de Qt. Ils y publient des projets, des idées propres et des composants afin d'obtenir les retours d'informations sur les API, le code et les fonctionnalités ou simplement pour partager avec nous ce qui les intéresse. Le code que vous y trouverez peut fonctionner tel quel, mais c'est sans aucune garantie ni support. Voir les conditions d'utilisation pour plus d'informations.
Nokia, Qt, Qt Labs et leurs logos sont des marques déposées de Nokia Corporation en Finlande et/ou dans les autres pays. Les autres marques déposées sont détenues par leurs propriétaires respectifs.
Cet article est la traduction de l'article Qt Graphics and Performance - Whats Hot and whats Not de Gunnar paru dans Qt Labs.
II. La documentation de QPainter▲
Vendredi dernier (NDT : le 11 décembre 2009), j'ai ajouté ce qui suit à la documentation de QPainter :
II-A. Performance▲
QPainter est un framework très complet permettant aux développeurs de réaliser une grande variété d'opérations graphiques telles que des gradients, différents modes de composition et des graphiques vectoriels. Et QPainter peut réaliser cela avec une grande variété de matériels et de logiciels. Naturellement, les combinaisons de matériels et de logiciels utilisées ont certaines conséquences sur la performance et s'assurer que chaque opération simple est rapide, quelle que soit la combinaison de modes de composition, de brosses, de découpage, de transformation, etc., est proche d'une mission impossible en raison du nombre de permutations possibles. Comme compromis, nous avons sélectionné certaines parties de l'interface et des moteurs de rendu de QPainter, pour lesquelles les performances sont garanties d'être aussi bonnes que possible pour une combinaison donnée de matériel et de logiciels.
Les moteurs de rendu parmi les plus performants sur lesquels nous nous sommes concentrés sont :
- Raster : ce moteur utilise une implémentation purement logicielle de tous les rendus, il est toujours utilisé pour le rendu de QImage. Pour des performances optimales, utilisez uniquement les formats QImage::Format_ARGB32_Premultiplied, QImage::Format_RGB32 ou QImage::Format_RGB16. Tous les autres formats, y compris QImage::Format_ARGB32, ont des performances moindres. Ce moteur est également utilisé par défaut sous Windows et sous QWS. Il peut être utilisé comme système graphique par défaut sur toutes combinaisons de systèmes, de matériels et de logiciels en passant la ligne de commande suivante : -graphicssystem raster ;
- OpenGL 2.0 (ES) : ce backend est le backend principal pour l'accélération matérielle graphique. Il peut être exécuté sur les ordinateurs de bureau et les systèmes embarqués supportant les spécifications de l'OpenGL 2.0 ou de l'OpenGL/ES 2.0. Ceci inclut la plupart des puces graphiques produites ces deux dernières années. Ce moteur peut être activé en utilisant QPainter dans un QGLWidget ou en passant la ligne de commande suivante : -graphicssystem opengl sur un système supportant ce moteur ;
- OpenVG : ce backend implémente la norme Khronos pour la 2D et les graphiques vectoriels. Il est utilisé principalement pour les périphériques embarqués avec un support matériel pour OpenVG. Le moteur peut être activé par la ligne de commande -graphicssystem openvg sur un système supportant ce moteur.
Les opérations les plus performantes sont les suivantes :
- les transformations simples, c'est-à-dire les translations, les mises à l'échelle et les rotations d'angles 0, 90, 180 et 270 degrés ;
- les fonctions drawPixmap() en combinaison avec des transformations simples et l'opacité, avec des modes de transformation sans lissage (QPainter::SmoothPixmapTransform n'est pas utilisé comme mode de rendu) ;
- le rendu de texte avec les tailles de police régulières, avec de simples transformations et avec des couleurs pleines, sans antialiasing ou avec un anticrénelage 8 bits ;
- le remplissage des rectangles avec une couleur unie ou un dégradé linéaire bicolore et une transformation simple ;
- le clipping rectangulaire avec des transformations simples et des intersections de régions ;
- les modes de composition QPainter::CompositionMode_Source et QPainter::CompositionMode_SourceOver ;
- le remplissage des rectangles avec des coins arrondis, avec une couleur unie ou un dégradé linéaire bicolore ;
- un masque de pixmap 3x3, avec qDrawBorderPixmap.
Cette liste donne une indication de fonctionnalités à utiliser en toute sécurité dans une application où la performance est décisive. Pour certaines configurations, d'autres opérations peuvent être rapides aussi, mais, avant d'en faire un usage intensif, il est recommandé de les comparer et de les vérifier sur le système où le logiciel sera finalement exécuté. Il est également possible d'utiliser des opérations coûteuses dans certains cas, par exemple lorsque le résultat est mis en cache dans un QPixmap.
Note : l'article original présente le code source de la documentation, destiné à être mis en page par qdoc3 ; la traduction présentée ici est mise en page directement.
III. Commentaires▲
Je pense que c'est une partie de la documentation que beaucoup d'entre vous ont attendue depuis un certain temps et c'est quelque chose que nous aurions dû ajouter depuis longtemps, mais je ne peux que dire « désolé de ne pas l'avoir fait plus tôt ». Au moins, cela est fait maintenant. Note : le patch n'est pas visible dans les dépôts publics au moment de la publication. Il devrait être soumis prochainement.
L'envie d'ajouter ces choses dans la documentation provient d'un certain nombre de conversations que j'ai eues récemment et qui ressemblaient un peu à cela :
- UneAutrePersonne : « Mon application est lente... Que dois-je faire ? »
- Moi : « Que fait-elle ? »
- UneAutrePersonne : « Eh bien, elle utilise QGraphicView et QPainter et fait ceci, cela... »
- Moi : « Cela ne semble pas trop mauvais. »
- UneAutrePersonne : « Puis ça devient très lent quand elle fait cela... »
- Moi : « Ouais... Ça ne marche pas très bien. Ce que vous devez faire, c'est ça... »
- UneAutrePersonne : « Est-ce écrit quelque part ? Comment suis-je supposé le savoir ? »
- Moi : « Euh... »
Pour remédier à cela, je vais mettre en action quelque chose que j'ai en tête depuis un moment déjà : une série d'articles sur Qt Graphics et les performances. En plus, je vais essayer d'ajouter des compléments dans la documentation ou dans des exemples et les démos comme de bonnes pratiques de cas d'utilisation.
Je dois simplement faire remarquer que cette série d'articles n'est pas une demande pour plus de fonctionnalités. Il s'agit pour nous de partager avec vous ce que nous considérons comme étant les meilleures pratiques et quelles sont nos priorités. Bien sûr, si vous pensez que nous nous écartons de notre objectif, faites-le-nous savoir, mais mon intention première de cette série d'articles est de partager quelques réflexions.
Avec l'aide de certains de mes collègues, nous avons l'intention de passer en revue certains principes de base de Qt Graphics, les moteurs à « hautes performances » et des cas d'utilisation des graphicsview et ses widgets. Si vous êtes intéressé par des cas d'utilisation particuliers, faites-le-moi savoir pour que je puisse éventuellement les aborder.
Je dois ajouter un petit commentaire sur le cas de drawText(). Actuellement, cette fonction n'est pas très optimale puisque nous devons faire la mise en forme du texte chaque fois qu'elle est appelée. Puisqu'il qu'il n'y a pas de « poignée » dans la fonction, nous n'avons pas la possibilité de mettre en cache la mise en forme. Si nous commencions à mettre en cache en nous basant sur une qHash de toutes les chaînes qui sont passées à drawText(), nous finirions par mettre en cache beaucoup de rendus de texte qui ne seraient utilisés qu'une seule fois... L'option que nous proposons actuellement pour contourner cela est d'utiliser un QTextLayout avec la mise en cache activée, ce qui est beaucoup moins gourmand en mémoire... Je pense que cela utilise environ 100 à 300 octets par caractère ! Donc, comme solution, nous travaillons sur une API pour le texte statique qui encapsule les travaux de mise en forme avec un coût très faible en mémoire. Elle est actuellement appelée QStaticText et nous prévoyons de l'ajouter dans Qt 4.7 (NDT : Qt 4.7 étant sorti, cette classe a été ajoutée). Une fois qu'elle sera mise en place, nous mettrons à jour le commentaire sur drawText dans la documentation sur les performances pour ces textes statiques...
Si le temps nous le permet, nous prévoyons d'aborder les thèmes suivants sur le blog :
- un aperçu des différentes composantes impliquées ;
- le moteur de rendu Raster en détail ;
- le moteur de rendu OpenGL en détail ;
- le moteur de rendu OpenVG en détail ;
- les options d'optimisation de QGraphicsView et les modes de cache.
IV. Divers▲
Au nom de toute l'équipe Qt, j'aimerais adresser le plus grand remerciement à Nokia pour nous avoir autorisés à traduire cet article !
Merci à littledaem et à johnlamericain et à dourouc05 pour leur relecture !