Est-ce que ces évolutions sont justifiées? Entre QCanvas, QGraphicView et QML, je ne saurais dire quel est/était le meilleur…
Il y a une logique derrière cette évolution. Évolution des possibilités techniques et des besoins.
QCanvas, c'était Qt3.
QGraphicsView est arrivé avec Qt4.2 comme une amélioration de QCanvas (et avec une API similaire). QGV profitait des évolutions du moteur d'affichage ainsi que d'optimisations sur la conso mémoire et la vitesse d'affichage.
QML est un changement d'orientation.
Il faut voir en parallèle l'évolution de la construction d'interfaces :
- en dur dans le code au début ;
- puis avec des fichiers de description "statiques" (.ui, XML mon amour) ;
- enfin, gestion des états/transitions des interfaces.
Au final si je dois faire un rendu, je prendrais plutôt opengl qui bien que plus primitif a l'avantage de rester rétrocompatible sur plusieurs décennies.
Comme ça, direct en OpenGL, sans rien au-dessus ? Avec chaque appli qui recode son truc dans son coin ? Et si OpenGL n'est pas disponible ?
[^] # Re: Obligé?
Posté par Olivier Serve (site web personnel) . En réponse au journal KDE from scratch. Évalué à 6.
Il y a une logique derrière cette évolution. Évolution des possibilités techniques et des besoins.
QCanvas, c'était Qt3.
QGraphicsView est arrivé avec Qt4.2 comme une amélioration de QCanvas (et avec une API similaire). QGV profitait des évolutions du moteur d'affichage ainsi que d'optimisations sur la conso mémoire et la vitesse d'affichage.
QML est un changement d'orientation.
Il faut voir en parallèle l'évolution de la construction d'interfaces :
- en dur dans le code au début ;
- puis avec des fichiers de description "statiques" (.ui, XML mon amour) ;
- enfin, gestion des états/transitions des interfaces.
Comme ça, direct en OpenGL, sans rien au-dessus ? Avec chaque appli qui recode son truc dans son coin ? Et si OpenGL n'est pas disponible ?