La fin de QGraphicsView : faut-il lui privilégier Qt Quick dans de nouveaux développements ?

Ce cadriciel ne devrait plus évoluer dans le futur

Avec Qt 4.2 est venue la vue graphique de Qt, un ensemble de classes qui s’articule autour de QGraphicsView. À l’époque, il s’agissait du summum du modernisme pour afficher de grands nombres d’éléments à l’écran. C’était en 2006. Quatre ans plus tard, une nouvelle manière de programmer des interfaces graphiques arrive : Qt Quick. Les principes sont totalement différents, il faut apprendre un nouveau langage de programmation (QML pour la description des interfaces, JavaScript pour la programmation proprement dite).

Ce nouveau venu fut, en réalité, une opportunité pour la vue graphique : la première version de Qt Quick l’utilisait pour son implémentation, guidait la danse pour les prochaines fonctionnalités et améliorations de performance. Depuis Qt 5.0, cependant, Qt Quick n’utilise plus les classes QGraphics pour son implémentation, mais bien un graphe de scène et un rendu directement avec OpenGL. Ce n’était pas un aveu de faiblesse de la vue graphique : ce cadre a été très utile pour proposer une version de Qt Quick performante, avec un temps de développement très réduit. Néanmoins, il s’agissait d’une couche d’abstraction pas forcément utile pour l’utilisateur final de Qt Quick et elle ne permettait pas toutes les optimisations nécessaires pour les ambitions que nourrissaient les développeurs envers Qt Quick. Depuis lors, la vue graphique n’a pas vu beaucoup de changements, comme le montre l’historique Git.

Une question revient alors souvent parmi les développeurs qui se lancent dans une nouvelle application avec Qt : plutôt QGraphicsView et compagnie ou bien Qt Quick ? Ce dernier n’est pas forcément un remplaçant pour toutes les utilisations de la vue graphique : au contraire, il lui manque un certain nombre de fonctionnalités, plus ou moins importantes selon les cas d’utilisation.

• QGraphicsView n’est qu’une manière de voir une scène (qui correspond à QGraphicsScene) : on peut disposer d’un grand nombre de vues d’une même scène, avec une très bonne performance (ces vues ne sont pas entièrement indépendantes pour les calculs).
  Au contraire, avec Qt Quick, cette fonctionnalité (pas si souvent utile, voire inutilisable dans bon nombre d’applications mobiles et embarquées) n’a pas été répliquée : pour y arriver, il faut impérativement créer plusieurs graphes de scène, à garder synchronisés. Cependant, cette simplification est à l’origine d’une grande simplification et d’un bon nombre d’optimisations du code de rendu.
  Pour y arriver avec Qt Quick, la meilleure manière de procéder est probablement de stocker toutes les données en dehors de Qt Quick (où sont répercutées toutes les modifications) et de n’envoyer que les parties intéressantes à chaque vue Qt Quick (créer un grand nombre de composants Qt Quick à l’exécution consommera beaucoup de mémoire). Le niveau de complexité est bien plus élevé que pour la même application QGraphicsView, mais avec le même niveau de flexibilité.
• Les QGraphicsItem disposent d’une solution de détection de collisions efficace, totalement absente de Qt Quick. C’est un réel handicap pour réaliser des jeux, vu que ces algorithmes doivent être implémentés pour chaque application — tout en faisant attention à la performance, souvent critique pour des jeux mobiles. L’infrastructure nécessaire est cependant arrivée avec Qt 3D.
• Qt Quick ne dispose, pour le moment, que d’une seule forme de base : le rectangle. Certes, il est très configurable (avec des bords arrondis, on peut dessiner des cercles, des ellipses), mais le niveau de fonctionnalité est très loin de celui proposé par la vue graphique et ses formes, personnalisables à l’infini.
  On peut émuler la chose avec le composant Canvas de Qt Quick (émulant l’API HTML5 du même nom, c’est-à-dire que le dessin est piloté en JavaScript, avec les problèmes de performance qui l’accompagnent), mais sans réelle intégration à l’environnement ; on peut aussi créer ses propres composants Qt Quick en C++ (ou en Python avec PyQt), voire créer ses propres nœuds pour le rendu dans le graphe de scène (ce qui apportera une performance maximale).
  Apparemment, il n’est pas impossible que la décision initiale de n’avoir qu’un rectangle comme forme soit en cours de révision : un développeur de Qt a développé un prototype de composant Qt Quick pour dessiner des formes arbitraires de manière entièrement déclarative (contrairement à Canvas) ; ce prototype est en cours d’intégration au code de Qt Quick depuis décembre dernier.
• La vue graphique est entièrement pensée pour le C++, il est très facile de créer ses propres classes. Au contraire, l’interface C++ de Qt Quick n’est pas pensée pour l’extension : un très grand nombre de composants n’a qu’une interface privée ; tout ce travail d’extension est censé être fait en QML (il est d’ailleurs encore plus aisé qu’en C++), mais la performance peut en pâtir.
  En d’autres termes, il n’est pas facile d’y accéder depuis son propre code et, de toute façon, les développeurs de Qt ne garantissent aucunement sa stabilité : tout code qui utilise directement les composants Qt Quick en C++ (par héritage, par exemple) n’a aucune garantie de continuer à fonctionner avec la prochaine version de Qt.
  Cette décision a beaucoup de sens : l’utilisateur peut toujours faire ce qui lui plaît en QML (le code ne sera pas complètement cassé par une mise à jour), tout en laissant aux développeurs de Qt la liberté de faire évoluer l’API C++, notamment à cause du jeune âge de Qt Quick.
  Heureusement, il semble que la politique à ce niveau soit en cours d’évolution, ces API pourraient être officialisées pour une prochaine version de Qt 5 (ou pour Qt 6). On pourrait même voir le graphe de scène facilement utilisable dans toute application C++ !

Quelles conclusions peut-on en tirer ? Les classes QGraphics ne sont plus vraiment développées, mais sont extrêmement stables et performantes, elles sont d’ailleurs utilisées dans un très grand nombre d’applications. Il n’est pas envisagé, pour le moment, de les retirer de Qt. Néanmoins, la politique actuelle de Qt indique clairement que Qt Quick est l’avenir pour la création d’interfaces graphiques : les nouvelles fonctionnalités de Qt sont d’ailleurs généralement utilisables aussi bien en C++ qu’en QML (comme Qt 3D).

Source : Should you still be using QGraphicsView?

Qu'en pensez-vous ?
— Qu’utilisez-vous pour vos applications, Qt Quick ou la vue graphique ?
— Quelle solution préférez-vous ?
— Envisagez-vous une migration de QGraphicsView vers Qt Quick ? Quels avantages en attendez-vous ?
— Qt 3D propose un très grand nombre de fonctionnalités, pas toutes orientées 3D, mais accessibles en C++ et depuis Qt Quick. Risque-t-on, à l’avenir, le même débat entre Qt Quick et Qt 3D ?