Discussion :

[Amnell]

De même, je présente ma participation.

Équipe
Moi

Participation
Pour le moment, la génération n'est pas des meilleures, je n'ai pas encore fait la coloration et le temps de génération est extraordinairement long (c'est de la génération en temps réelle). Je me suis assez concentré sur l'esthétique du programme et donc sur l'interface. Je vais coder un système de génération par multithread, ce qui devrait augmenter considérablement la vitesse de génération.

[dourouc05]

Participation
Pour le moment, la génération n'est pas des meilleures, je n'ai pas encore fait la coloration et le temps de génération est extraordinairement long (c'est de la génération en temps réelle). Je me suis assez concentré sur l'esthétique du programme et donc sur l'interface. Je vais coder un système de génération par multithread, ce qui devrait augmenter considérablement la vitesse de génération.

Niveau génération, ça donne quoi ? Tu as des résultats plus convaincants ? Et la coloration, tu nous a préparé quelque chose ? (Une coloration spéciale qui donne un bouddha encore plus vrai que nature ?).

Pour le multithread, tu t'en sors ? Avec des résultats ?

[Amnell]

Actuellement, c'est un peu en pause, donc je n'ai ni travaillé sur la coloration, ni sur le multi-threading, ce qui n'aide pas.
En terme de résultat, j'obtiens des chose à partir de 10 000 itérations, ce qui prend la nuit à cause du temps réel, et ça n'a que l'allure.
Bref, il reste encore pas mal de travail !

[yan]

En terme de résultat, j'obtiens des chose à partir de 10 000 itérations, ce qui prend la nuit à cause du temps réel, et ça n'a que l'allure.

EN gros tu dessines en "temps réel" l'avancement de l'image c'est cela?
A mon avis tu fait beaucoup trop de rafraîchissement. D'où le temps énorme.

[Amnell]

Oui, cela prend dix mille huit cent fois trop de temps, quand on pense qu'il est possible d'arriver à 4 secondes de génération.
Pour l'affichage, j'ai cru comprendre qu'il faudrait générer des points plus ou moins gros et de couleur plus ou moins noire selon le nombre de points dont la zone d'influence est superposée, c'est bien cela ?
Ce que je veux dire par là, c'est que si nos taches que l'on affiche à l'écran sont d'une taille de cinq pixels, et que dans cette zone de cinq pixels, il y a déjà un autre point de taille cinq pixels : faut-il modifier la couleur en fonction de la couleur des deux ? En gros, on ne gère rien du tout, on met juste une opacité et la superposition de points modifie elle-même la couleur.
Je ne sais pas si j'ai dit quelque chose de compréhensible mais bon, si quelqu'un a compris et s'il a la réponse à cette question, qu'il n'hésite pas !

[khayyam90]

Il n'y a pas cette notion de points plus ou moins gros. Chaque itération incrémente la valeur du point (unique) correspondant à l'affixe courante dans la suite fractale.
Une coloration pourra alors mettre en clair les points à fortes valeurs.

[Amnell]

Voilà, j'ai retiré la mise en temps réel de la génération : 2 minutes pour 5 000 itérations au lieu de plus d'une nuit en temps réel, soit un gain de performances attendu, mais déjà excellent, bien que le programme gèle à cause de cela : je ne me suis toujours pas lancé dans le multithreading.
Malgré tout, le résultat ne ressemble pas à grand chose - pour ne pas dire à rien.

Exemple de rendu avec 2500 itérations (on voit la forme mais ça ne va pas plus loin) :



Avec 5000 itérations :

[yan]

comment tu tire les points de départ ?

[Amnell]

comment tu tire les points de départ ?

Avec un code très moche, car si l'utilisateur demande trop d'itérations, ça va engendrer une boucle infinie. Ce code de tirage avait pour seule utilité de permettre de tester le reste.
Je compte refaire ce système d'ici peu, étant en train de retaper entièrement la partie de génération.

Je vous préviens tout de suite, c'est très moche :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
for(int n = 0; n < it; n++)
{
	double tmpX = (qrand() % (4000)) - 2000;
	double tmpY = (qrand() % (4000)) - 2000;
	tmpX /= 1000;
	tmpY /= 1000;
	if(list.indexOf(std::complex<double>(tmpX, tmpY)) != -1)
	{
		n -=1;
		break;
	}
	list.append(std::complex<double>(tmpX, tmpY));
}

[yan]

Y as des chances quune partie du problème vienne de là.
En principe, tu as très peu de chance de te retrouver avec deux complex identique. Donc

Code :

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

list.indexOf(std::complex<double>(tmpX, tmpY)) != -1)

est plutôt inutile.

[Amnell]

En effet, j'ai placé un qDebug() dans la condition est elle ne s'est pour le moment jamais montrée vraie.
J'arrive dès maintenant avec des chiffres plus concrets.

Pour 2500 itérations :

• Début à 14h 46min 17sec
• Tous les calculs (tout sauf l'affichage des points) finis à 14h 46min 25sec
• Affichage à l'écran fini à 14h 46min 39sec

Soit un total de 22 secondes pour 2500 itérations.

[khayyam90]

Le tirage des points de départ peut être sujet à polémique, est-il préférable de tous les considérer ou bien de n'en prendre qu'une petite partie ?

[yan]

Le tirage des points de départ peut être sujet à polémique, est-il préférable de tous les considérer ou bien de n'en prendre qu'une petite partie ?

Je dirais que cela doit être très proche du mandelbrot.
Certain point donnera que quelques points, d'autre beaucoup.

[Amnell]

Le tirage des points de départ peut être sujet à polémique, est-il préférable de tous les considérer ou bien de n'en prendre qu'une petite partie ?

Ici, je n'en prends qu'une partie en tirant aléatoirement.
Les considérer tous correspondrait à avoir une fractale plus complète, non ?
Je referai la gestion des points de départ selon ce que vous pensez être le mieux.
Petite question : le centre de la fractale est bien sensé se trouver avec le point de départ 0 ?

[khayyam90]

Les considérer tous correspondrait à avoir une fractale plus complète, non ?

absolument, il faudrait au moins une base de test commune entre toutes les participations ne serait-ce que pour comparer les performances.

[yan]

absolument, il faudrait au moins une base de test commune entre toutes les participations ne serait-ce que pour comparer les performances.

le code fournie ne ferai pas l'affaire?

[Amnell]

le code fournie ne ferai pas l'affaire?

Pas trop non, ce n'était qu'un code temporaire qui avait pour unique but de permettre d'afficher la fractale.
Je reprendrai cette partie d'ici peu, pour, si besoin, vous en montrer une qui soit correcte.

[yan]

Pas trop non, ce n'était qu'un code temporaire qui avait pour unique but de permettre d'afficher la fractale.

Temporaire oui, mais pas non plus mauvais en performance.
Et il as surtout l'avantage d'être hors concours.

[Amnell]

De retour, j'ai modifié mon code toute la soirée pour effectuer deux modifications.
La première était sur le tirage aléatoire des points. J'en ai fait un qui soit un minimum propre. Gain d'environ deux secondes.
La seconde est l'arrivée du multithreading (au moins trois points en plus dans la note ). Je me suis bien pris la tête avec des explosions diverses et variées (genre : QThread::start() : failed to create a thread (Code d'accès non valide) qui m'aura fait chercher une bonne demie-heure), mais j'ai fini par réussir à mettre cela en place. Seul défaut, une minute de temps de génération en plus, pas de bol . Sans doute parce que la création de threads est lente, j'ai donc du travail avant de pouvoir attaquer réellement l'affichage qui est des plus horribles.

EDIT : Et autre défaut, trois minutes pour fermer l'application à cause de la destruction de la totalité des threads créés.

[yan]

regarde QTHreadPool et QtConcurrent.