Discussion :

[gerald3d]

Bonjour.

Je reviens pour la nième fois sur le sujet qui a déjà été plus ou moins traîté 1 million de fois .

Le projet actuel est un logiciel de traitement d'images. Ces traitements prennent, vous le comprenez bien, un temps d'exécution qui par la force des choses "bloquent" l'IHM.

Jusqu'à présent j'incorporais dans mon code la boucle classique while (gtk_events_pending ()) .... Mais j'en arrive rapidement à la limite. L'IHM se bloque quand même durant le traitement malgré cet appel.

La mise à jour ne concerne qu'une ou plusieurs barres de progression. Mais peu importe, l'important c'est le principe.

Donc j'en appelle à votre savoir et grande sagesse . Je ne vois que deux solutions (c'est déjà pas mal me direz-vous) à mon problème:

1. Trouver un drapeau qui pourrait m'indiquer à coup sûr que tel widget est effectivement rafraîchi. Sans cet accord j'attends. Problème; le traitement risque de s'éterniser!
2. Utiliser les threads. Je vois déjà que Teuf prend son clavier . Je te rassure un g_idle_add(); devrait suffire.

[teuf13]

Jusqu'à présent j'incorporais dans mon code la boucle classique while (gtk_events_pending ()) ....

classique mais moche

Mais j'en arrive rapidement à la limite. L'IHM se bloque quand même durant le traitement malgré cet appel.

ca veut dire que tu ne l'appelles pas suffisamment souvent/aux bons endroits ? Ou t'as des traitements vraiment longs que tu ne peux pas fractionner ? Si c'est la 2ème solution, un g_idle_add ne suffira pas (vu que ça bloquera la main loop donc le rafraîchissement).Des threads, c'est pas la mort si tu fais ultra gaffe à ce que tu fais

[gege2061]

Salut,

As tu essayé de regardé comment fait gimp pour générer la barre de progression de son écran de démarrage ?

L'animation reste fluide, pourtant les traitements doivent être assez important (surtout lors du premier démarrage).

Sinon, la seconde solution me semble la meilleure

J'ai déjà utilisé g_idle_add pour remplir un GtkTreeView avec des info d'une base de données.

Pour résumer, lors de la construction je lançai le thread via g_idle_add, j'appelle ensuite une fonction qui va boucler sur le résultat de la requête et à chaque ligne appeler une fonction de rappel afin que j'ajoute une ligne dans le tree view. Après chaque ajout de ligne, je redonne la main à GTK+ (avec gtk_process_events).

Peut être qu'un peux de code sera plus clair :

• Fonction pour remplir le tree view : populate_tree_view
• Fonction qui lance la requête SQL et appel la fonction callback : get_statistics

[liberforce]

Si ton traitement est morcelable, alors g_idle_add avec une machine d'état suffira.

Au passage, ton cas 1 est une mauvaise approche.

Si tu as un fonction qui prend beaucoup de temps et sur laquelle tu n'as pas de contrôle (ce n'est pas toi qui l'as développée, elle vient d'une bibliothèque externe, tu n'as pas le temps de la refaire proprement, etc.), alors la seule solution est d'utiliser un thread séparé.

Utilise GTimer avec des printf, ou sysprof pour trouver la fonction qui prend beaucoup de temps à s'exécuter si tu sais pas laquelle c'est.

[gerald3d]

Merci pour vos réponses.

Après réflexion il me semble que le thread pure, c'est à dire externe à la boucle GTK+, est la solution à mon problème.
Lorsque j'applique une matrice 7x7 par exemple sur une image faisant 3040X2014 j'aimerai avoir une progression linéaire. Bien sûr je ne suis pas obligé de faire avancer la barre à chaque pixel traité mais tout de même le processeur est utilisé à pleine puissance.

Donc si on part sur le thread d'autres problèmes vont surgir. Comment interagir avec la boucle principale GTK+?

Ma première idée est la suivante:

1. Création d'un thread du processus.
2. Création d'un thread interne via g_idle_add();. Ce thread va "écouter" une donnée qui typiquement sera la valeur de progression.
3. Dans le thread du processus la donnée sera modifiée au fur et à mesure de l'avancement.
4. Le processus terminé kill des deux threads.

Le soucis va venir de la donnée commune. Dois-je implémenter un mutex dessus? Et l'idée vous parait-elle réaliste?

[teuf13]

hmm, g_idle_add ça ne crée pas de thread ni rien, c'est juste un signal comme un autre qui est appelé très souvent. Donc tu ne peux pas bloquer dans un g_idle_add. Par contre, quand tu veux modifier ta donnée partagée, tu peux tout simplement faire un g_idle_add pour "transférer" la valeur au thread principal (un callback de g_idle_add est toujours appelé depuis le thread principal, c'est ce qui fait tout son intérêt).

[liberforce]

Merci pour vos réponses.

Après réflexion il me semble que le thread pure, c'est à dire externe à la boucle GTK+, est la solution à mon problème.

Bin justement, d'après ce que tu écris, plus bas, non
Je te file des liens pour ce que j'ai tenté de t'expliquer plus haut rapidement : il faut utiliser un design pattern qui s'appelle le "lazy loading".
J'ai vu cet exemple la première sur planet.gnome.org il y a 3 ans. C'était un post écrit par Emmanuele Bassi, développeur sur GTK, Clutter, etc.
http://blogs.gnome.org/ebassi/2006/03/30/lazy-loading/
Le lien dans son post est cassé, mais heureusement, archive.org est là pour jouer son rôle de mémoire du web.
http://web.archive.org/web/200710100.../lazy-loading/

La technique : une machine d'états, le traitement effectué dans chaque état étant suffisamment cours pour ne pas bloquer la boucle principale trop longtemps. C'est un jeu de ping pong : la main loop te donne la main dans une callback, à toi de lui rendre la main rapidement. Sinon c'est comme si un des joueurs d'une partie de ping pong gardait la balle : l'autre ne peut rien faire en attendant (et donc les widgets ne sont pas redessinés).

Lorsque j'applique une matrice 7x7 par exemple sur une image faisant 3040X2014 j'aimerai avoir une progression linéaire. Bien sûr je ne suis pas obligé de faire avancer la barre à chaque pixel traité mais tout de même le processeur est utilisé à pleine puissance.

Hé bien morcelle le traitement en lignes... Stocke où tu dois reprendre le traitement (la ligne suivante), et rends la main, en mettant à jour la barre de progression. Tu peux aussi choisir de traiter un certain nombre de pixels à la place. La seule chose importante, c'est que le temps nécessaire pour traiter ce lot de pixels soit suffisamment court pour ne pas geler l'interface.

Donc si on part sur le thread d'autres problèmes vont surgir. Comment interagir avec la boucle principale GTK+?

Ma première idée est la suivante:

1. Création d'un thread du processus.
2. Création d'un thread interne via g_idle_add();. Ce thread va "écouter" une donnée qui typiquement sera la valeur de progression.
3. Dans le thread du processus la donnée sera modifiée au fur et à mesure de l'avancement.
4. Le processus terminé kill des deux threads.

Le soucis va venir de la donnée commune. Dois-je implémenter un mutex dessus? Et l'idée vous parait-elle réaliste?

g_idle_add ne crée pas de thread. Il n'y a pas d'exécution en parallèle. C'est le thread principal (la main loop) qui te donne la main pour faire ton traitement, c'est tout.

Pour en savoir plus sur tout ce qui est "j'ai un thread qui bosse et une IHM à mettre à jour", renseigne toi sur ce qu'on appelle les "worker thread".

[gerald3d]

Merci pour tout. J'ai du "décorticage" de code à faire pour comprendre tout ca .

[liberforce]

Je peux la faire plus courte sinon, c'est un peu équivalent en pseudo code à :

Code :

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

1
2
3
4
5
6
 
pour chaque lot de pixels de l image:
    traiter un lot de pixels;
    mettre à jour la barre de progression;
    traiter les évènements en attente;
fin pour

où "traiter les évènements en attente" est :

Code :

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

1
2
while (gtk_events_pending ())
    gtk_main_iteration ();

A toi de voir pour la taille des lots, des lots trop grands et tu auras toujours le même problème de rafraîchissement, des lots trop petits et tu auras des performances de traitement dégueu vu que le cache processeur sera complètement sous optimisé.

L'automate aurait été un peu plus nécessaire si tu avais différents types d'actions à opérer, là le petit coup de gtk_events_pending/gtk_main_iteration est sans doute suffisant et plus lisible.