Je comprend ton idée mais ça me pose problèmeLes exemples "temps réel" livrés avec Qt utilisent un QTimerEvent pour déclencher l'update. Dans l'exemple il fixe l'intervalle à 20ms. Dans la doc ils disent que si l'on met cet intervalle à 0ms l'action est lancé dès que la pile d'évènement est vide mais dans un même temps ils disent que la précision sur la plupart des plateformes est de 20ms. Cette précision intervient quand l'intervalle est > 0 ou bien même quand elle est égal à 0 ?
Diminuer l'intervalle à moins de 20 ms (50 FPS) n'a aucun intérêt puisque de toute façon, on ne percevra pas les images supplémentaires (en gros. on peut en effet augmenter un peu le FPS pour la qualité de rendu des animations rapides dans les jeux mais aucun intérêt non plus de monter à 1000 FPS).
Pour les calculs "temps réels" selon ta définition, dans le domaine scientifique, on privilègera la justesse des résultats. Et si le calcul ne peux pas être fait en temps réel, on changera la base de temps tout simplement. Et si on veut du temps réel quand même, on ne fera que les calculs en temps réel, pas l'affichage de toutes images (puisque le résultat ne sera pas visualisable).
Pour être concret, si tu veux étudier un phénomène d'écoulement qui dure 1/2 seconde avec un intervalle de temps de 5 µs, tu n'as aucun intérêt à afficher 100000 images en 1/2 seconde.
En voyant ça, j'ai l'impression que tu fais des calculs et du transferts de données vers le GPU à chaque rendu... A priori, le coût de la surcouche Qt dans ce cas (à voir le code de tes 2 fonctions membres) doit être vraiment négligeable par rapport au reste.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7 void GLWidget::paintGL() { onUpdate(); // fonction membre perso onRender(); // fonction membre perso update(); // QWidget::update() }
Pour revenir au problème Qt : celui-ci ne prend en charge que la partie CPU de l'application (events, boucles, signaux/slots, etc.) Si le programme est bien conçu, la totalité du rendu sera réalisé par le GPU et le coût apporté par Qt sera minime. Et dans le pire des cas, il faudra threader la partie QtOpenGL (ce qui est déjà possible sans attendre Qt 4.8... mais pas simple)
Pour en revenir à la question initiale, Qt peut tout à fait être utilisé pour des animations "scientifiques" mais par contre, ce n'est pas un moteur. Tu peux aussi regarder du côté de Qt3D (un nouveau module Qt en cours de dev qui ajoute beaucoup de choses aux fonctionnalités de base offerte par QtOpenGL)
Partager