Rafraîchissement de l'interface.

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 :D . 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 :lol:. Je te rassure un g_idle_add(); devrait suffire.

Citation:

---

Envoyé par gerald3d

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

---

classique mais moche ;)

Citation:

---

Envoyé par gerald3d

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 :)

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

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.

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?

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).

Citation:

---

Envoyé par 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.

---

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).

Citation:

---

Envoyé par gerald3d

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.

Citation:

---

Envoyé par gerald3d

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".

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

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

Code:

---

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:

---

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.

Jusqu'à présent j'utilise ce principe. J'avoue que ma répartition est vraiment à ch... puisque l'IHM gèle. Je pourrai effectivement revoir cette répartition.
Maintenant le côté "Lazy Loading" est intéressant. Aimant bien me faire mal à la tête sur de nouveaux problèmes, je pense que je vais m'orienter vers ce principe tout en creusant mon idée aussi ;).

Quelle taille font tes lots actuellement ? Combien de temps prend l'exécution d'un lot (utilise GTimer et mets des traces). Tu as au moins besoin de ces informations pour savoir où tu vas...

J'en prends note. Je te donne juste un exemple. Téléchargement de 15 images de 35Mo chacune puis traitement du lot complet pixel par pixel (calcul des valeurs médianes, moyennes, ecart type ... j'en passe et des meilleurs).
Déjà ici je ne contrôle pas la fonction de chargement. C'est GdkPixbuf qui s'en charge. Ca pose ici un problème puisque je n'ai aucun contrôle là dessus. Pour le rest c'est la partie que je vais travailler. je vais lancer quelques GTimer pour voir.

C'est ton appli qui doit se charger du télécharger des images ? On parle bien de téléchargement à partir d'une autre machine, hein, pas du chargement en local à partir de GdkPixbuf ?

Tu nous avais pas tout dit, petit cachotier... Vu sous cet angle, si tu as aussi le téléchargement (bloquant) + chargement dans GdkPixbuf (bloquant ? faut tester avec une petite et une grosse image) + traitement à écrire... Bin les threads sont peut être une meilleure solution... Un thread de téléchargement, qui alimente une file d'attente pour le thread de chargement + traitement, et le rafraichissement des widgets dans le thread principal... Faudra juste utiliser des Mutex pour la file d'attente... Par contre le débogage est plus compliqué ensuite...

Faire le téléchargement en asynchrone doit être possible (est-ce que gio serait utile ici ?), mais en l'état actuel de mes compétences, je ne saurais pas comment faire. Faudrait poser la question sur la gtk-app-devel mailing list...

Non non.J'ai employé le mot téléchargement par habitude. Tout ce fait en local. Donc pas de problème de ce côté là.

http://audidude.com/blog/?p=278 peut peut être t'être utile, même si a priori tu sais déjà quelle fonction bloque ta mainloop.

Ca a l'air intéressant comme application. La forme graphique semble très lisible. Merci pour l'info.

C'est utile pour voir les temps d'attente entre évènements graphiques, mais ça ne donne pas non plus la fonction fautive... Pour ce type de recherche, il vaut mieux utiliser Sysprof.

Je vais finir par ne faire plus que du "profiling" ;). Merci pour cette info aussi.