Problème de déclenchement de QTimer dans QGIS (Quantum GIS)

Question

J'ai participé à la création d'une application custum QGIS dans laquelle les données en temps réel doivent être affichées sur le visualiseur de l'application.

L’IPC utilisé est une file de messages Unix.

Les données doivent être actualisées à un intervalle spécifié, par exemple 3 secondes.

Maintenant, le problème auquel je suis confronté est que le traitement des données à afficher prend plus de 3 secondes. Ce que j’ai fait est donc que, avant que l’application ne commence à traiter les données pour la prochaine mise à jour, l’actualisation QTimer est arrêté et, une fois les données traitées, je redémarre à nouveau QTimer.L'application doit fonctionner de telle manière qu'après une mise à jour / une actualisation (pendant cette actualisation, l'application ne répond plus), l'utilisateur doit disposer de suffisamment de temps pour continuer à travailler sur l'ordinateur. en plus de voir les données en cours de mise à jour.Je peux obtenir des pauses acceptables pour que l’utilisateur puisse travailler-- dans un scénario.

Mais sur des systèmes d’exploitation différents (RHEL 5.0 à RHEL 5.2), la situation est différente. Le temporisateur se déchaîne et continue de se déclencher sans faire de pause, avec les mises à jour successives, créant ainsi une boucle infinie. Manipulation définitive des données de mise à jour prend plus de 3 secondes, mais c’est pour cette raison que j’ai arrêté-redémarré le chronomètre en cours de traitement..et la même logique fonctionne dans un scénario alors que dans un autre il ne le fait pas .. L’autre fait que j’ai observé c’est que de la minuterie, le temps pris par la fonction de rafraîchissement pour sortir est très petit, environ 300 ms, de sorte que l’arrêt-départ de la minuterie que j’ai placé au début et à la fin de cette fonction se produit dans ce laps de temps peu Le traitement réel des données se termine, il y a 3 ou 4 démarrages du temporisateur dans la file d'attente qui attendent d'être exécutés et le problème de la boucle infinie s'aggrave à partir de ce point pour chaque mise à jour successive.

La chose importante à noter ici est que, pour le même code dans un système d'exploitation, la durée d'actualisation est d'environ 4000 ms (le temps de traitement réel utilisé pour la même quantité de données), tandis que pour l'autre système d'exploitation, ses 300 ms.

Peut-être que cela a quelque chose à voir avec les nouvelles bibliothèques sur le système d'exploitation mis à jour..mais je ne sais pas comment le déboguer parce que je ne suis pas en mesure de comprendre pourquoi cela se produit en tant que tel ... peut-être que quelque chose lié à pthreads a changé b / w les systèmes d'exploitation ??

Donc, ma question est la suivante: y at-il un moyen d’assurer que certains traitements de mon application sont temporisés (et qui sont indépendants du système d’exploitation) sans utiliser QTimer, car j'estime que QTimer n'est pas une bonne option pour atteindre vouloir ??

Quelle option peut être là ?? des pthreads ou des threads Boost? Quel serait le meilleur choix si je voulais utiliser des threads comme substitut? Mais comment puis-je m'assurer qu'au moins un décalage de 3 secondes entre les mises à jour successives, quelle que soit la durée du traitement de la mise à jour?

Merci de votre aide.

Merci.

Answer 1

Si j’essayais d’obtenir une solution acceptable à plus long terme, j’envisagerais de mettre à jour votre affichage dans un fil distinct. Dans ce fil, vous pouvez peindre l'affichage en une image, en le mettant à jour aussi souvent que vous le souhaitez ... bien que vous souhaitiez peut-être l'étrangler pour 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’un minuteur (tout redessiner à partir de la source), ou l’autre thread peut émettre un signal chaque fois que les nouvelles données sont complètement actualisées.