Discussion :

[yan]

[edit] Ceci est une discussion déplacée d'un autre sujet


C'est pas terrible l'exemple de mandelbrotalors...
http://qt.developpez.com/doc/4.3/threads-mandelbrot/
il utilise un signal :

renderedImage(const QImage &, double)

C'est pas thread safe!!!
Surtout qu'avec le COW,

renderedImage(const QImage, double)

Aurai suffit!!! ou y as encore un truc qui m'échappe?

[IrmatDen]

Si, grâce à l'utilisation d'une QWaitCondition sur la variable restart qui n'est positionné à true, que lorsque tu zoom/drag.
Une boucle du code de run n'est exécuté qu'à ces moments, pas en permanence. Hors, lorsque l'image est accédée dans le thread GUI, il est *impossible* de faire un rendu d'image puisque les zoom et drag sont contrôlés par le thread GUI. D'où l'impossibilité de corrompre cette image.

Mais en effet, un const QImage aurait été suffisant (et je n'ai pas de réponses à pourquoi utiliser une ref constante dans la majorité de ces cas :/)

[yan]

J'ai enfin compris une grande partie du schimilibilik.
Merci pour la patience
Nykoo, si tu veut bien, je veut bien faire la partie sur le connect entre thread?

Bon faudra que je regarde cette histoire de QWaitCondition. Je voit pas pourquoi ca rendre safe l'échange de l'image entre les deux thread...

Merci

[IrmatDen]

En fait non, c'set moi qui ai lu le code trop rapidement tout à l'heure, mea culpa (désolé de t'avoir induit en erreur, par contre, j'ai l'explication réélle ce coup-ci )

J'ai un peu fouillé les sources concernant QPixmap, et en fait fromImage (tant qu'elle de format RGB32, ARGB32_Premultiplied ou RGB16) fait simplement un pixmap.data->image = image; (cf src/gui/image/qpixmap_raster.cpp)
Donc en réalité, l'assignation est immédiate (puisque cow) et lors de la modification dans le thread, les données de QPixmap sont "déliées" des données de l'instance QImage dans le thread.
Donc en fait l'image est à cause de ça incorruptible. (Et par parallèle, j'aurais tendance à dire que la ref const QString& suit le même principe si tu ne l'utilises pas telle quelle, mais en l'assignant à une variable locale)

[yan]

En fait non, c'set moi qui ai lu le code trop rapidement tout à l'heure, mea culpa (désolé de t'avoir induit en erreur, par contre, j'ai l'explication réélle ce coup-ci )

Héhé ca me rassure

J'ai un peu fouillé les sources concernant QPixmap, et en fait fromImage (tant qu'elle de format RGB32, ARGB32_Premultiplied ou RGB16) fait simplement un pixmap.data->image = image; (cf src/gui/image/qpixmap_raster.cpp)
Donc en réalité, l'assignation est immédiate (puisque cow) et lors de la modification dans le thread, les données de QPixmap sont "déliées" des données de l'instance QImage dans le thread.
Donc en fait l'image est à cause de ça incorruptible. (Et par parallèle, j'aurais tendance à dire que la ref const QString& suit le même principe si tu ne l'utilises pas telle quelle, mais en l'assignant à une variable locale)

Je ne suis pas d'accord , ce n'est pas incorruptible. Mais c'est peu probable.
1- Une image est généré et un signale est envoyé
2- Un event est émis dans la thread principale
3- Seulement la thread principale fait un truc super long
4- l'autre thread à déjà commencé à faire quelque chose puisque reçu un nouveau zoom et position auparavant => modifie la QImage
5- Et la la thread principale traite l'event => QImage as changé => corrompu

Je suis d'accord que dans ce code c'est peu probable. Mais dans un autre code...

[IrmatDen]

3- Seulement la thread principale fait un truc super long
4- l'autre thread à déjà commencé à faire quelque chose puisque reçu un nouveau zoom et position auparavant => modifie la QImage

Ces 2 points sont incompatibles
Si le thread principal fait un truc long:
> pas possible de faire de zoom
> pas possible de faire un drag
> possible qu'il y ait une ou plusieurs itérations supplémentaire dans le thread
> mais comme il ne peut pas y avoir de rafraichissement entre temps puisque le thread GUI est occupé à autre chose, tout va bien (je parle toujours dans ce cas bien sûr).

Bien sûr, dans un vrai soft il est préférable de partir sur une autre solution (par exemple, un "anneau" d'images, ie, tu as 10 instances de QImage dispo dans le thread, chaque fois qu'une est générée, tu utilises la suivante en émettant la dernière créée; arrivé à la 10ème, tu repars de 0 en partant du principe que la première a largement eu le temps d'être utilisée. Si elle est pas, y'a quelque chose qui va *vraiment* pas du côté de la gui )