Bienvenue sur le forum !

Si vous souhaitez rejoindre la communauté, cliquez sur l'un de ces boutons !

Qt 5 : 5.9.1 - Qt Creator : 4.3.1 - Qt Installer : 2.0.3 - JOM : 1.1.2 - Qt Build suite : 1.7.0 - VS Qt 5 : 2.0.0

Besoin de deux QThread

November 2013 modifié dans OpenCV
Bonjour à tous :P

Je viens sur ce nouveau forum (pour moi) car sur developpez.net je ne trouve pas la réponse 8.(

J'ai fait une classe ProcessVideo qui surclasse QThread
Cette classe fait la lecture d'une vidéo, fait des traitements sur les frames et envoie un signal à la main pour afficher l'image après traitement.

Tout ceci marche très bien. Et je sais que j'aurais pu aussi faire processVideo.moveTo(&monThread).

Mais ma question est la suivante. Dans la méthode qui traite les frames, parfois je fais des traitements sur un canal (gray) mais parfois je fais un traitement, le même disons, sur chacun des 3 canaux.
Je me suis dit que ce serait bien d'utiliser aussi un petit thread (3 instances d'un thread) qui traiterait les 3 canaux en même temps et à la fin je reconstitue mon image (merge).

Mais comme ma classe ProcessusVideo est déjà un QThread, je me demande si j'ai le droit de faire un QThread dans un autre QThread? :rolleyes:

Si ceci n'est pas possible cela veut dire que je doit revoir toute mon architecture de processus de mes frames... 8.(

Si quelqu'un avec plus d'expérience que moi en Qt peut m'aguiller ce serait super sympa. Merci bien!!:)

sur developpez.net il y a le bisou mais pas ici enfin il y a ceci mais moins joli {)

Réponses

  • Bonsoir,
    QThread permet la programmation de traitement parallèle, je t'apprend rien. Et cela nécessite une réflexion sur le flot des traitement (avec un graphe de flot par exemple). Tu te poses pas les bonnes questions.
    Qu'est ce qui doit être réellement parallélisé ?
    Rien si ton traitement est suffisamment rapide pour ne pas détériorer la GUI.
    Sinon 1 seul QThread pour la fonction de traitement des 3 canaux. Comme il n'y a qu'une seule sortie du résultat de la fonction de traitement qui sera utilisé par la GUI, il n'y a vraiment aucun intérêt de paralléliser les 3 canaux. Pire, un thread à un coût en ressource.
    @+
  • Bonsoir
    merci de ta réponse
    je ne suis pas sûre d'avoir compris.

    ce n'est pas UNE function qui traite les 3 canaux, c'est la même fonction appellée 3 fois : une fois pour chaque canal et comme c'est un traitement assez lent je me suis dis que peut-être les paralléliser ce serait une bonne idée.

    Chaque appel de la fonction retourne un résultat et à la fin des 3 appels je fais le merge pour le résultat final.

    J'ai l'impression que tu as compris que je traiter les 3 canaux ensemble, ou c'est moi qui n'ai pas compris ton explication. Je suis désolée!!! :(

    merci de ta réponse en tout cas
  • Bonjour,

    Je n'ai jamais fait plus d'un thread à la fois, mais pour vraiment "paralléliser" regardes du côté de Qt Concurrent.
    Je n'ai jamais utilisé mais c'est vraiment fait pour le multi-thread

    Bon courage
  • November 2013 modifié
    Ce n'est pas par ce que tu as 3 traitements lents qu'ils failles les paralléliser.
    Dans ton cas, c'est le résultat mergé de tes 3 traitements qui sera envoyé au thread GUI, la parallélisation est inutile.
    La multiplication des thread n'est utile que si plusieurs résultats doivent être envoyés au thread GUI et que chaque résultat est le fruit d'un traitement qui peut être bloquant ( comme par exemple les galeries d'image, les communications réseaux client/serveur...)
  • Merci pour ta réponse

    Je ne comprends pas pourquoi je ne peux pas paralléliser une fonction lancées trois fois c'est à dire que f2 doit attendre que f1 termine et f3 doit attendre que f2 termine alors que je pourrais les faire en parallèle car elle n'ont aucune dépendence?
    chacune travaillant sur un array distinct. :(

    QtConcurrent et le Watcher ne permettent pas de faire ce genre de choses?
    Seulement dans le cas de libérer le GUI cette parallélisation est utile?

    Désolée j'ai du mal à comprendre mais tu as sûrement raison puisque je ne connais pas encore bien Qt

    merci encore ! :)
  • Aucune contre-indication à lancer un thread depuis un thread (en fait le thread principal, "GUI" est aussi un thread).

    Traiter chaque canal séparément te permettra d'optimiser ton process sur les machines ayant la puissance requise pour faire tourner 3 thread plein pot en même temps.

    Si tu peux isoler le "traitement" dans une classe, une méthode, les classes QtConcurrent et cie sont les plus facile à mettre en oeuvre, sinon tu peux tout aussi bien créer tes thread à la main (en sous classant QThread) mais il faut être sûr de ce qu'on fait.

    Enfin on ne relis jamais assez le topic suivant: http://qt-project.org/wiki/Threads_Events_QObjects
  • Le principe des thread n'est pas propre à Qt.
    image
    Comme indiqué par la flèche rouge sur l'image ci-dessus, tu n'as qu'un point d'entrée vers la GUI.
    D'un point de vu développeur, la méthode 2 est plus lourde à mettre en place, consommant globalement plus de ressources. Mais le traitement peut être plus rapide sur machine multi-coeur.
    Seul l'architecture de ta machine cible te permettra de choisir la méthode 1 ou 2
  • Ok, j'ai compris merci à tous les deux
    ma machine n'étant que dual-core, je ne gagnerai pas beaucoup car j'ai déjà un thread pour le gui et un autre pour le processus général de la vidéo.

    ... dommage

    merci encore {)
Connectez-vous ou Inscrivez-vous pour répondre.