[python 2.*.*] Traitement avec affichage et update d'une ProgessBar().

Salut les pygtk,

j'ai un tableau, dont la taille peut varier, assez grand (environ 300000 items), que je doit traiter en affichant l'avancement du traitement avec une progressBar().
Le problème étant que j'arrive uniquement a implémenter une ProgressBar() grâce a la méchanique de timeout:

Code:

---

gtk.timeout_add(1, fonction_de_traitement)

---

Ce qui ralentis le traitement a une milliseconde une unité (item) du tableau...

Si vous connaissez d'autres techniques d'optimisation ou d'implémentation de mon problème, ça serai sympa de poster.

Merci pour vos réponses éclairées.

Bonjour Luke,

Les PB ne sont pas le widget que j'utilise le plus, mais j'en utilise de temps en temps quand même.

Sur le principe, tu a deux fonctionnements possibles (je fais light ;) ):
-Mode gauche droite: tu ne sait pas quantifier l'avancement, alors tu fait en sorte que ta PB ai un curseur allant de gauche à droite et vice-versa.
-Mode standard: tu sait quantifier ton avancement. ta barre évolue progressivement.

Dans ce dernier mode de fonctionnement, tu as deux solutions:
-Indiquer la valeur que tu souhaites affichée
-Envoyer un pulse, en ayant défini précédemment ton pas d’évolution.

Dans ces deux cas, tu n'as à ma connaissance que la possibilité de le faire en direct (ex: une boucle ou tu implémente directement la mise à jour), ou bien la méthode que tu utilise, à savoiir, définir un timeout_add qui va régulièrement meetre à jour ta PB.

Je peux me tromper (que quelqu'un me corrige dans ce cas si possible), mais je pense que tu n'aura rien de mieux que le timeout_add.

Merci pour ces illuminations,

mais il s'avère que si l'on implémente bêtement une boucle et que l'on met le code de update (par avancement ou par pulsation) de le ProgressBar() dedans la il faut attendre la fin de la boucle avant que la ProgressBar() ne change quoi que ça soit a son apparence souvent a la fin de la boucle la ProgressBar() se remplis rapidement.
C'est pour cette raison que j'ai utiliser un timeout grâce auquel je peut traiter les éléments du tableaux 1 par milliseconde en accédant a l'index actuel et en l'incrémentant pour le timeout suivant jusqu'a arriver a la fin de mon tableau en affichant une progressbar...

Ce qui fait que j'ai un programme qui rame car ont ne peut configurer de timeout, a ma connaissance, plus petit que la milliseconde.

En tout cas j'ai ce comportement sur mon système.

Merci pour vos réponses.

Ah ah... c'est donc cela qui te gene.

OK, donc je voit mieux ton soucis. EN fait cela est du a la façon dont GTK fonctionne. Il faut imaginer un thread parallele en quelque sorte. Et effectivemet, dans certains cas, la mise à jour n'a lieu qu'à la fin. C'est notemment cela qui donne parfois l'impression que l'IHM se fige (hang en anglais pour tes futures recherches).

regarde la doc officielle ICI.

Il y a en fait une certaine façon de faire pour effectuer la mise à jour. J'espère que je cerne bien ton probleme, sinon on va trouver ;)

Ouais,

En faites j'ai réussis a optimiser un peu la vitesse de traitement en implémentant une boucle qui boucle sur 100 unité du tableau a chaque exécution du timeout qui est paramétré a chaque milliseconde...

Sur mon ordinateur, qui est une belle bête:
Processeur Intel I7 quad core cadencé a 3.4 GigaHZ (Je peut l'overlocker a 3.9).
8 Giga de RAM.
etc ...
Cela fonctionne parfaitement.
Et je ne sais pas si c'est une pratique a risque si le programme s'exécute sur un ordinateur plus lent ?

Et ton lien semble intéressant pour amélioré encore la vitesse d'exécution. GTK est vraiment vaste et l'on ne peut pas tout en connaître. Merci pour le lien.

Citation:

---

J'espère que je cerne bien ton probleme, sinon on va trouver

---

Tu a mis dans le mille, en plein dedans, merci pour ces illuminations.

Marrant,

J'ai presque la meme becane (i7 4770k @3.5GHz, avec 16G de ram), comme pas mal de dev je pense :mouarf:

Ta question est excellente, et j'avoue que mon expérience indique que tout depend de la becane cible et de notre programme. Des fois cela fonctionnera sans soucis (en general), des fois pas du tout (tres rarement), et beaucoup de nuance entre les deux. La plupart du temps en fait, c'est juste que ton programme sera plus lent, et/ou donnera l'impression de ramer.

C'est pour cette raison que j'ai recupere un vieux PC (genre 5-6 ans), qui tourne sous Linux Mint 14. C'est pas un foudre de guerre et ça me permet de tester un minimum en situation réelle. SInon la seule solution que j'ai à proposer c'est des VM. Mais tu n'émule pas à la perfection un vrai vieux PC.

Salut en faîte,

j'ai mis une une possibilités de configuration de la vitesse d'exécution allant de 10 a 100 opérations sur la table a traiter par milliseconde ou timeout et j'ai remarquer que pour les boucles ou le traitement est lourd le seul side-effect d'une vitesse d'exécution trop rapide est un défaut d'affichage de la ProgressBar() qui ne s'affichent pas correctement, par contre le résultat du traitement reste inchangé...

Par contre pour le lien concernant les threads dans gtk j'arrive a les implémenté mais:

*) j'ai un traceback après le l'exécution du thread qui me dit que je ne restaure pas le contexte de thread et ayant fait un:

Code:

---

1 2 3 4 5 6 7 8 9 10

for v in dir(gobject) : if v.lower().__contains__('thread') : print v # Je cherche une fonction pour restaurer le contexte   # Ou sinon pour l'autre manière d'implémenter un thread dans gtk   for v in dir(gtk) : if v.lower().__contains__('thread') : print v # Je cherche une fonction pour restaurer le contexte

---

Je rentre bredouille car je n'ai pas trouver de fonction pour restaurer le contexte et puis j'ai pas chercher plus loin car:

*) Ma méthode d'exécuter 10-100 opérations dans un timeout se révèle être beaucoup plus rapide que l'implémentation de threads, en faite l'exécution d'un thread revient au même qu'a exécuter une opération par timeout... surprenant peut-être que les threads sont basés sur une exécution a la milliseconde ?

Sinon j'ai aussi un système de VM.

Mais puisque l'on aborde le sujet, quels sont les distributions les plus connus qui utilisent le système de paquetage *.deb car le tutoriel de deusyss sur DEBREATE m'a grandement aider dans la construction de paquet *.deb.

Maintenant il faut tester sur les distributions qui utilisent le système de paquetage *.deb

Je sais déjà que c'est les distribution basées sur debian ce qu'il me faut c'est des nom de distribution, ça serai sympa de votre part si vous désirez bien apporter votre pierre a l'édifice de donner un|des nom(s) des distribution(s).
Que je puisse tester dans une VM.

Merci pour vos réponses éclairées.

PS: J'ai aussi 16 Giga de RAM je me suis tromper.