Problème de QTimer dans QGIS (Quantum GIS)

Question

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.

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.

Answer 1

Si j'essayais d'obtenir une solution acceptable à plus long terme, je chercherais à mettre à jour votre affichage dans un fil séparé. Dans ce fil, vous pouvez peindre l'affichage sur une image, en le mettant à jour aussi souvent que vous le souhaitez ... bien que vous souhaitiez limiter le fil de sorte qu'il ne prenne pas tout le temps de traitement disponible. Ensuite, dans le fil de l'interface utilisateur, vous pouvez lire cette image et la dessiner à l'écran. Cela pourrait améliorer votre réactivité au panoramique, car vous pourriez afficher différentes parties de l'image. Vous pouvez mettre à jour l'image toutes les 3 secondes en fonction d'une minuterie (juste redessiner à partir de la source), ou l'autre thread peut émettre un signal chaque fois que les nouvelles données sont complètement rafraîchies.