Affichage + lecture de données GPS : utilisation d'un deuxième thread ou non ?

Bonjour à toutes et à tous,

Dans l'application GPS que je crée, la partie graphique prend plus de temps que prévu et de ce fait, bloque la lecture du flux d'information du GPS (via BlueTooth associé à un port série).

J'ai trouvé une parade, qui consiste à vider le tampon de lecture du GPS quand la taille des infos non lues dépasse un certain niveau.

On va dire que ça fonctionne, mais cela ne me satisfait pas vraiment.

Je me pose la question de l'utilité d'un thread dans ces conditions.

Le thread principal ferait tourner la partie graphique et, dans le thread secondaire, la lecture des infos GPS se ferait au rythme des envois par le GPS ; je stockerais dans un emplacement mémoire les infos qui m'intéressent, à chaque fois qu'elles arrivent.

Après chaque mise à jour du graphique dans le thread principal, je viendrais lire, dans le thread secondaire, les infos que j'ai stockées pour les utiliser pour une nouvelle mise à jour du graphisme dans le thread principal.

Est-ce que cela vous paraît convenable.

NOTA : je n'ai jamais fait joujou avec les threads.

Cordialement.

Pierre

salut

j'aurais fait l'inverse ... le graphisme est conditionné par l'arrivé de donnée gps
je ne vois pas a quoi sert ton thread principal pour gerer le graphisme



un exemple sympa ici

Bonjour ! Ça me paraît être une bonne idée.

Soit dit en passant, il y a peut-être moyen d'améliorer les performances de la partie graphique ?

Citation:

---

Envoyé par Roland Chastain

... il y a peut-être moyen d'améliorer les performances de la partie graphique ?

---

C'est ce que j'aimerais faire. J'ai montré ce qu'elle est dans le fil que j'ai créé sur le clipping.

Cordialement.

Pierre

Après lecture de l'autre discussion, le temps d'exécution de la partie graphique me paraît normal. Donc effectivement, pourquoi pas deux processus. Maintenant, quoi mettre dans lequel, j'ai un doute après avoir lu le message d'anapurna. :)

Citation:

---

Envoyé par Roland Chastain

Après lecture de l'autre discussion, le temps d'exécution de la partie graphique me paraît normal. Donc effectivement, pourquoi pas deux processus. Maintenant, quoi mettre dans lequel, j'ai un doute après avoir lu le message d'anapurna. :)

---

J'ai cru comprendre qu'un thread secondaire ne pouvait pas traiter de l'affichage ?

"One of the threads is called the Main Thread. The Main Thread is the one that is created by the Operating System once our application starts. The Main Thread must be the only thread that updates the components that interfaces with the user: otherwise, the application may hang."

Cordialement.

Pierre

En effet, le thread secondaire ne peut pas agir directement sur l'affichage : il doit le faire au moyen de la méthode Synchronize ou d'une autre méthode équivalente.

Citation:

---

Envoyé par Roland Chastain

En effet, le thread secondaire ne peut pas agir directement sur l'affichage : il doit le faire au moyen de la méthode Synchronize ou d'une autre méthode équivalente.

---

J'ai commencé à faire une ébauche de cette structure et ça a l'air de pas mal se passer. la partie réception/lecture des données GPS a l'air fluide (sous Windows). Je n'ai pas de Linux opérationnel pour l'instant ; je ne peux pas voir dans cet environnement sur PC.

Toutefois, mon application est destinée à tourner avec un Raspberry Pi 3B (sous Raspbian Stretch) avec un écran tactile de 7 " et 1024 x 600 pixels². Dans cet environnement, la réception/lecture des données semble fluide, mais se gèle au bout de quelques minutes. Apparemment, le tampon ne se surcharge pas. Je ne vois pas d'où cela peut provenir pour l'instant. Ce gel me semble trop répétitif pour être dû à une défaillance physique du Raspberry, mais ... ?

Cordialement.

Pierre