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

Le , par dourouc05, Responsable Qt
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de frfancha frfancha - Membre confirmé https://www.developpez.com
le 23/01/2017 à 12:05
Bonnes questions. Je suis curieux de voir les réponses des spécialistes QT de developpez.
Avatar de Jbx 2.0b Jbx 2.0b - Membre expérimenté https://www.developpez.com
le 23/01/2017 à 13:52
Pour ma part, après des années à manipuler des QGraphicsView/Scene, que ce soit pour faire de la réalité augmentée sur des vidéos ou sur un rendu 3D, je suis passé depuis un an à QtQuick. Ce n'a pas toujours été sans douleur car les Qt Quick Controls 1.x sont pour beaucoup bogués, incomplets, ou difficilement personnalisables. Mais il y a tellement à y gagner, entre autre:

- Un code beaucoup moins verbeux que les héritages de QGraphics*Item en pagaille (ou pire les QGraphicsProxyWidget...).
- Une séparation parfaitement nette de la vue (qml) et du modèle (C++).
- Une gain de productivité énorme.
- Les performances du graphe de scène sont sans cesse améliorées, et vont bientôt proposer des rendus via Vulkan et DirectX 12.
- Le QML est maintenant mis en cache (en Qt 5.8) et sera bientôt compilé (ce qui est déjà le cas dans la version commerciale, il me semble). De même la mise en cache des shaders est prévue en 5.9.
- Les Qt Quick Controls 2 sont magnifiques, et proposent des rendus type Material (Google) et Universal (Microsoft)

Bref, autant on a essuyé un peu les plâtres cette année en commençant un projet avec Qt 5.4 (le résultat est quand même magnifique), autant cette année avec l'arrivée de Qt 5.8 (aujourd'hui ) je n'aurais aucun regret à proposer QtQuick, même pour une application desktop type client lourd.

Edit: De même, avec l'intégration d'OpenVG en Qt 5.9, j'imagine qu'on devrait avoir de sérieux concurrents à QGraphicsShapeItem.
Avatar de GilbertLatranche GilbertLatranche - Membre actif https://www.developpez.com
le 23/01/2017 à 20:37
Je développe essentiellement pour desktop.

--- Je vois QGraphicsView comme une bonne solution pour construire des tools élaborés (par exemple un node graph, ou une timeline) sans écrire directement de l'OpenGL. QtQuick 2 est apparu mais n'est à mon sens toujours pas un remplaçant crédible, en cause : toutes les critiques adressées par l'auteur du post initial, la lourdeur d'une simple QQuickView, l'API Javascript des QQuickControls que je trouve d'une pauvreté absolument phénoménale par rapport à ce qu'il est possible de faire avec QtWidgets.

QtQuickControls2 corrige une partie des défauts de la version 1, mais il manque toujours :

- quelques widgets absolument indispensables pour du desktop : treeview, tableview, et je souhaite bon courage aux mainteneurs pour obtenir des performances pas trop dégueulasses ;
- et si je ne me trompe pas, un look&feel natif. Je prends pour exemple qt3d-editor : non, des checkboxes ou spinboxes de 12 mètres de haut, ça ne le fait pas.

--- Je m'exerce avec QtQuick depuis quelques temps, c'est puissant mais le passage ne se fait pas sans douleur.

De toute façon, le module QtWidgets est considéré comme stable, pour ne pas dire "fini" et QGraphicsView était critiqué sur plusieurs points.

Cependant, bonne nouvelle, parmi les logiciels desktop bien lourds, les softs Allegorithmic utilisent QML pour une partie de leurs interfaces, preuve que QtQuick est à peu près utilisable sur ces bonnes vieilles plateformes.

--- L'objectif de Qt3D n'est clairement pas le même que celui de QGraphicsView et QtQuick. Il ne faut pas perdre de vue que le core de Qt3D repose sur un pattern spécifique qui ne convient pas à toutes les applications.

Sinon, l'ouverture prochaine de certaines API privées de QtQuick est une excellente nouvelle. L'écriture d'UI en mode JSON est très pratique, mais ******** de *******, je ne suis pas venu sur un framework C++ pour enchaîner les courses pieds nus sur verre pilé avec Javascript.
Avatar de Jbx 2.0b Jbx 2.0b - Membre expérimenté https://www.developpez.com
le 24/01/2017 à 9:43
quelques widgets absolument indispensables pour du desktop : treeview, tableview, et je souhaite bon courage aux mainteneurs pour obtenir des performances pas trop dégueulasses
TableView existe depuis Qt 5.1, TreeView depuis Qt 5.5
Les performances sont bonnes, et le rendu et les interactions utilisateurs sont modernes (effets type ressort en haut et bas de page par exemple).

l'API Javascript
J'vais être grossier mais: on s'en fout de Javascript ! On code son code métier et ses modèles en C++, l'IHM en QML, et Javascript sert juste de colle pour ajouter des petites interactions , des animations, à la limite des validateurs sur les champs... ça aurait pu être du python ou n'importe quel langage de script, ça revenait au même. Maintenant si d'autres veulent développer leur appli uniquement en JS/QML, pourquoi pas, mais ils n'atteindront pas le même niveau de fonctionnalités que le C++, et c'est normal.

- et si je ne me trompe pas, un look&feel natif. Je prends pour exemple qt3d-editor : non, des checkboxes ou spinboxes de 12 mètres de haut, ça ne le fait pas.
Teste l'application exemple "Qt Quick Controls 2" donnée avec Qt 5.8. Teste la sous Windows, teste la sous Android, Linux, MacOS, iOS... Franchement, c'est propre, c'est fluide. Et les thèmes Material et Universal on un rendu quasi identique sur chaque plateformes.
Avatar de GilbertLatranche GilbertLatranche - Membre actif https://www.developpez.com
le 24/01/2017 à 16:22
Citation Envoyé par Jbx 2.0b Voir le message
TableView existe depuis Qt 5.1, TreeView depuis Qt 5.5
Les performances sont bonnes, et le rendu et les interactions utilisateurs sont modernes (effets type ressort en haut et bas de page par exemple).
C'est du QtQuickControls 1

Citation Envoyé par Jbx 2.0b Voir le message
J'vais être grossier mais: on s'en fout de Javascript !.
Dieu, que tu es violent

Citation Envoyé par Jbx 2.0b Voir le message
On code son code métier et ses modèles en C++, l'IHM en QML, et Javascript sert juste de colle pour ajouter des petites interactions , des animations, à la limite des validateurs sur les champs... ça aurait pu être du python ou n'importe quel langage de script, ça revenait au même. Maintenant si d'autres veulent développer leur appli uniquement en JS/QML, pourquoi pas, mais ils n'atteindront pas le même niveau de fonctionnalités que le C++, et c'est normal.
Je vais tenter de mieux expliquer : j'implémente une lib de property browsers pour QtWidgets et QtQuick (il paraît que c'est le futur alors je prévois) et je souhaite que l'utilisation reste la même entre les deux versions. Le backend est en C++. Un des browser widgets implémentés est une tree view. Et comparé à QTreeView, utiliser (Quick)TreeView provoque des sueurs froides. La version QML n'offre pas plusieurs fonctionnalités très utiles, et paradoxalement, sa doc, qui est un des points forts de Qt, est incomplète.

Citation Envoyé par Jbx 2.0b Voir le message
Teste l'application exemple "Qt Quick Controls 2" donnée avec Qt 5.8. Teste la sous Windows, teste la sous Android, Linux, MacOS, iOS... Franchement, c'est propre, c'est fluide. Et les thèmes Material et Universal on un rendu quasi identique sur chaque plateformes.
Je note ça, merci. Mais ce n'est pas du Material ou Universal qui va remplacer les classes dérivées de QStyle. Je suppose que cela viendra plus tard au vu des objectifs initiaux de QtQuickControls 2.
Avatar de dourouc05 dourouc05 - Responsable Qt https://www.developpez.com
le 24/01/2017 à 17:31
Citation Envoyé par GilbertLatranche Voir le message
paradoxalement, sa doc, qui est un des points forts de Qt, est incomplète.
En fait, je pense que c'est un point faible de Qt Quick : autant j'aime bien la doc C++ de Qt, autant j'ai du mal à m'y retrouver avec Qt Quick, à trouver l'info que je cherche…
Avatar de PocoYote PocoYote - Membre régulier https://www.developpez.com
le 24/01/2017 à 20:13
Je n'utilise pas QT, mais cette plate-forme m'a toujours attiré (elle attire tous ceux qui pratiquent le C++).

Donc de temps en temps je télécharge et je jette un œil aux exemples.
Depuis l'introduction de Qt Quick, j'avoue ne pas toujours comprendre comment fonctionnent les exemples. Avant, avec les Qt Widgets, c'était facile et le code était beau.
Je trouve le mélange C++ / Javascript vraiment lourd, et finalement je ne comprends pourquoi tout n'est pas en C++.

Bon ok mon avis ne compte pas vraiment.
Avatar de dourouc05 dourouc05 - Responsable Qt https://www.developpez.com
le 24/01/2017 à 21:38
Citation Envoyé par PocoYote Voir le message
Bon ok mon avis ne compte pas vraiment.
Si, parce que ton avis est sûrement plus représentatif de débutants . Effectuer le lien entre du code C++ et QML n'est pas forcément trivial (et ça l'est encore un peu moins en Python avec PyQt, je trouve). Ça n'est pas particulièrement compliqué, mais ça nécessite de s'y connaître plus que de raison, je trouve.
Avatar de Jbx 2.0b Jbx 2.0b - Membre expérimenté https://www.developpez.com
le 26/01/2017 à 9:50
C'est du QtQuickControls 1
Exact, au temps pour moi !
Offres d'emploi IT
Expert décisionnel business intelligence H/F
Safran - Ile de France - Évry (91090)
Ingénieur H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Spécialiste systèmes informatiques qualité et référent procédure H/F
Safran - Ile de France - Colombes (92700)

Voir plus d'offres Voir la carte des offres IT
Responsable bénévole de la rubrique Qt : Thibaut Cuvelier -