J'ai participé à la construction d'une application custum QGIS dans laquelle les données en direct doivent être affichées sur le visualiseur de l'application.Problème de QTimer dans QGIS (Quantum GIS)
L'IPC utilisé est des files d'attente de messages Unix.
Les données doivent être actualisées à un intervalle spécifié, par exemple 3 secondes. Maintenant, le problème que je suis confronté est que le traitement des données à afficher prend plus de 3 secondes, donc ce que j'ai fait est qu'avant que l'application commence à traiter les données pour la prochaine mise à jour, le refresh QTimer est arrêté et après le traitement des données je redémarre à nouveau le QTimer.The application devrait fonctionner de telle sorte qu'après une mise à jour/actualisation (pendant cette actualisation l'application ne répond pas) l'utilisateur devrait avoir suffisamment de temps pour continuer à travailler l'application en dehors de voir les données mises à jour.Je suis en mesure d'obtenir des pauses acceptables pour l'utilisateur de travailler - dans un scénario. Mais sur des OS différents (RHEL 5.0 à RHEL 5.2), la situation est différente. Le temporisateur se déchaîne et continue à se déclencher sans donner de pauses b/w les mises à jour successives se passant ainsi dans une boucle infinie. prend certainement plus de 3 secondes, mais pour cette raison, j'ai arrêté - redémarré la minuterie en cours de traitement .. et la même logique fonctionne dans un scénario tandis que dans d'autres, il ne .. L'autre fait que j'ai observé est que lorsque rapide le déclenchement de la minuterie se produit le temps pris par la fonction de rafraîchissement pour sortir est très petit environ 300ms donc le début-arrêt de la minuterie que j'ai placé au début et fin de cette fonction se produit dans ce petit temps ... donc avant le traitement effectif des données se termine, il y a 3-4 démarrages du temporisateur en file d'attente en attente d'exécution et ainsi le problème de boucle infinie s'aggrave à partir de ce point r chaque mise à jour successive. La chose importante à noter ici est que pour le même code dans un OS, le temps de rafraîchissement est d'environ 4000ms (le temps de traitement réel pour la même quantité de données) tandis que pour l'autre OS il est de 300ms. Peut-être que cela a quelque chose à voir avec de nouvelles libs sur le système d'exploitation mis à jour ... mais je ne sais pas comment le déboguer parce que je ne peux pas comprendre pourquoi cela se produit en tant que tel ... peut-être quelque chose en rapport avec pthreads changé b/w les systèmes d'exploitation ?? Donc, ma question est qu'il y a un moyen de s'assurer que certains traitements dans mon application sont minutés (et qui est indépendant du système d'exploitation) sans utiliser QTimer car je pense que QTimer n'est pas une bonne option pour atteindre ce que je veux??
Quelle option peut-il y avoir ?? Pthreads ou Boost threads? lequel serait mieux si je dois utiliser des threads comme une alternative ?? Mais comment puis-je m'assurer au moins un intervalle de 3 secondes b/w mises à jour successives, peu importe combien de temps le traitement de mise à jour prend?
Veuillez nous aider.
Merci.
autre erreur que je crois est que la commande d'arrêt-démarrage du temporisateur est dans le code d'exécution qui résulte du déclenchement de ce même QTimer lui-même ie lorsque les instructions d'arrêt-démarrage pour le prochain cycle d'exécution sont exécutées le QTimer est actif pour ce cycle même en cours d'exécution, tout mauvais impact dû à ceci, à des suggestions? En fait, cette fonction de rafraîchissement est non seulement appelée parce que le temporisateur est déclenché mais aussi lors du zoom/panoramique du spectateur. traitement pour le temps que l'utilisateur zoome/pans afin de garder l'application sensible, et bien sûr pour éviter les erreurs – ashishsony