Discussion :

[Luke spywoker]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[deusyss]

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.

[Luke spywoker]

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.

[deusyss]

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

[Luke spywoker]

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.

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.

[deusyss]

Marrant,

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

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.