Discussion :

[sayag]

Bonjour,

mon appli graphique est d'une effroyable lenteur,
particulièrement pour le refresh()

devrais je utiliser un invalidate() ou un refresh() pour aller plus vite ?

a part améliorer mes algo, y at il d'autres choses à faire pour booster tout ça ?

[theMonz31]

salut

Si ton appli graphique est lente, cela peut provenir de plusieurs choses.

1/ Tu dessines via des bcp de controles utilisateurs ou bien tu as "1" seul controle qui gère tout l'affichage ?

(par exemple, imagine un jeu de dame, si chaque case est un control (ou une pictureBox, ca sera bcp plus lent que si il y a un unique objet echiquier dessiner dans une seule méthode)

2/ As tu penser aux options SetStyle() avec les flags d'optimisation, de double buffering, etc.. ?

3/ Si ton dessin est vraiment complexe (genre du fais de la 3D en GDI+), peut-etre que l'utilisation de DirectX (ou MDX) peut s'avérer salutaire

4/ Regarde tes algorithmes pour vérifier qu'il ne manquerait pas des dispose qui te feront gagner en gestion de la mémoire.. Dans le OnPaint, regarde si tu as beaucoup de "new" d'allocation que tu pourrais eviter de refaire ou au pire,
centraliser au début du Paint() et donc, les sortir d'eventuelles boucles de traitement dans le OnPaint();

5/ Peut-etre que tu fais des calculs dans ton OnPaint() qui pourrait ne pas avoir lieu... Par exemple, si tu calcules des courbes etc... il serait mieux
d'avoir la mise à disposition des elements à afficher pour que le OnPaint se focalise sur l'affichage et non sur de l'évaluation de données

Voici quelques pistes, j'espère que cela te permettra d'entrevoir une solution pertinente et convaincante

The Monz, Toulouse

[sayag]

Merci TheMonz
J'ai une quasi infinité d controle utilisateur.
Je fais une appli graphique pour la retroprojection d ecran sur une table a controle tactile, ou interface tangible.
Donc il y a autant de controleur possible que de doigts.
es doigts ouvrent une fenêtre. A l interieur de laquelle se trouve un echiquier, justement et ou chaque case est instanciée.
De plus, pire encore, chaque case et comme une masque flouteur, ou filtre passe bas, puisqu elle se superpose a des microcases et affiche en son centre le nombre de microcases qu elles contient, ce qui impose une grande quantité de if/for...
Ce n'est sinon pas de la 3D, je me suis penché sur DirectX et j'ai chopé le SDK mais je suis pas sûr que ca résoudra mes problème.
Concernant le double buffering, je me suis renseigné, ca pourrait améliorer les choses, mais je suis un peu sceptique, car l'affichage final dépend quans meme d'une methode, enfin abc un core2duo ca meroterait ptetre d etre testé.
Les setStyles(), je ne connaissais pas.
Enfin je ne fais rien d'autres que du dessin dans mon OnPaint, quoique faut que je vérifie, mais via les méthode appelée j'ai pas mal de new.
Sinon Dispose() systematique mais je ne suis pas sur de les appliquer au bon moment.

[theMonz31]

ok ravi que tu es pu trouver des pistes

Sinon, je te donne mon opinion d'architecte .Net....

Essaye si tu peux de remplacer TOUS tes controles par un unique Draw...

En clair, il faudrait que toutes les informations pour dessiner soit accessible
via le Draw de ton principal control...

Tant que TOUS tes controles se dessineront eux meme, tu auras ce type de problème.. Car , il faut savoir que chaque controle va prendre un event "OnPaint", et vu la quantité que tu en as.. ca devient vite "dement"

On voit bien dans ton cas la limite d'utilisation des controles dans ce type de contexte...

The Monz, Toulouse

[sayag]

oui, mais en fait il y a aussi un problème plus personnel,pour moi, ayant créé mon ode à partir d'un code similaire mais primaire, la methode OnPaintBackground(paintevent...) est en fait la seule où quelquechose s'exécute.

Ce qui fait que lorsque j'ai besoin de faire des calculs, qui concernent par exemple la position des zones, leur présence ou pas dans une zone (contains, IsVisble...), etc, je les fait dans mon OnPaint().

Ca doit être une catastrophe non ? Mais où les faire sinon ?
Mon Mian() appelle la classe qui le contient, je n'y a donc que ça :

Code :

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

1
2
3
 
ClasseContenante demo = new ClasseContenante(param1, parm2);
Apllication.Run(demo);

Ce qui fait que pour exclure ce qui ne "paint" pas de mon OnPaint, enfin bref, je ne sais pas où le mettre, et du coup être parti d'un code préfait m'a fait passer à côté des bases

[theMonz31]

beh, le mieux serait d'appeler le code qui modifie les paramètres seulement
quand tu sais quand ceux ci ont changés...

En gros, ta fonction de calcul des données doit etre appelé quand les données
à évaluer ont changées...

Et dans ce cas là, un Invalidate() forcera le OnPaint() puisque les données
auront changés.. sinon, ton OnPaint() va etre appelé et calculer tout le bazar
meme quand il n'y aura lieu que de faire un refresh

Donc, soit ta une fonction qui fait ce boulot, soit tu peux aussi positionner un
boolean dans ton onPaint() et si le boolean est à true, tu ré-évalues avant
de dessiner, sinon, tu dessines "brutalement"...

The Monz, Toulouse

[sayag]

en fait c'est déjà ce que je fais,
c'est là que je ne comprends plus mon code

En fait mon OnPaint ne se lance que si les données ont changé,
car il se lance à chaque PaintEvent, et ceux ci sont dépendant d une action extérieure, et mes seules données sont modifiées uniquement par les actions extérieures.

En fait mes données sont semblable à celles engendrées par plusieurs souris sur un même écran...

En clair, je ne dessine pas en boucle à chaque pas de temps, je dessine uniquement quand il y a aciton de l'utilisateur.
Mais le problème vient par exemple de quand je glisse mon doigt d'un bout à l'autre de l'écran : le Invalidate() se fait constament, ainsi que le Paint(), et là ca clignote effroyablement, à faire palpiter un epileptique

[theMonz31]

re

beh, si tu veux sauver les épyleptique, tu peux par exemple trapper l'event
OnMouseMove et positionner un flag pour dire, je bouge, je ne rafraichis pas...

Mais bon, ca risque de ne pas plaire à tes utilisateurs

Une autre solution "pertinente" serait de ne rafraichir que ce qui a pu bouger
quand tu sais que l'utilisateur se déplace sur ton application...

Du genre, si Mon application a le Focus(), alors je sais que je ne dois redessiner
qu'une partie de mon écran... Si par contre, j'ai perdu le Focus() , la prochaine
fois que j'aurais le Focus() , je devrais tout redessiner

Evidemment, cela reste de la bidouille... car l'essentiel serait bien sur d'avoir
un rafraichissement optimal t'évitant de faire des cas particuliers en fonction
de l'utilisation de ton application

Mais, il me vaudrait voir le code pour donner un diagnostic et une solution
plus "pertinente" maintenant

The Monz, Toulouse

[sayag]

si tu y tiens mais c'est pas un cadeau :

[theMonz31]

ok

ca serait "plus" simple de m'envoyer le projet par mail

The Monz, Toulouse