Eviter les nombreux appels à OnPaint dûs au nombre de contrôles présents sur le form

**jerome.vanhoof** · 30/08/2007, 15h40

Bonjour,

Je suis actuellment occupé à améliorer les performances visuelles d'une application winform.

J'ai remarqué que les méthodes OnPaint et OnPaintBackground d'une Form ou d'un UserControl étaient appelées à chaque fois qu'un contrôles de cette form ou de ce user control était dessiné.

Faites le test : nouveau projet avec une seule winform, overridez OnPaint dans le classe Form1 et dedans Console.WriteLine("OnPaint");

protected override void OnPaint(PaintEventArgs e)
{
Console.WriteLine("OnPaint");
base.OnPaint(e);
}

On lance l'applic.
la sortie nous donne une seule ligne.

Rajoutons maintenant 2 boutons sur la form.
On lance l'applic.
la sortie nous donne 3 lignes (donc 3 passages dans OnPaint).

Ceci est également valable pour OnPaintBackground.

Je comprends bien qu'il soit nécessaire que ces méthodes soient appelées après que les boutons soient dessinés un à un, cependant, cela peut devenir fort coûteux en performance.

Exemple : lorsqu'un user control passe de visible=false à visible=true, le background du user control va se peindre autant de fois que le user control contient de contrôles et il y a dès lors, je pense, un risque de scintillement.

Quelqun connait-il, dans cet exemple, par exemple, un moyen d'éviter ces multis paint et de ne peindre le tout une bonne fois pour toute, une fois tous les contrôles dessinés ??

Ou bien fais-je fausse piste ?

Merci d'avance pour vos impressions ainsi que votre savoir

**neptune** · 30/08/2007, 15h55

Je pense sincèrement que tu dois laisser ce genre de considération au framework. Les mecs qui l'ont mis au point ont probablement pensé à cela et je pense que l'affichage des controles est déjà optimisé.

**tomlev** · 30/08/2007, 16h12

Ce n'est pas parce que tu passes dans la méthode OnPaint que tout est redessiné... en fait seule la partie invalidée est réellement redessinée (la propriété ClipRectangle du PaintEventArgs)
Enfin, je ne suis pas tout à fait sûr de comment ça marche, mais quand je fait un Paint personnalisé, si j'invalide toute la zone à dessiner, il y a un "clignotement" de l'image parce que tout est rafraichi, alors que si seule une petite partie est invalidée, je n'ai pas ce clignotement : seule la zone invalidée est rafraichie. Pourtant je ne me préoccupe pas dans le code de savoir quelle est la zone invalidée, je suppose que c'est géré par le Framework ou par GDI+

**Pol63** · 30/08/2007, 17h08

pour répondre à certains, la gestion du graphisme du framework est une vrai merde
une centaine de label qui clignotent : vb6 : 1% d'utilisation du pross
vb.NET2 : 50%

gdi+ n'utilise pas d'accélération matérielle

une des méthodes pour gagner un peu de temps et de réécrire une partie des controles ...
en réérivante le label on arrive à 2 ou 3 %

**jerome.vanhoof** · 30/08/2007, 23h02

Envoyé par tomlev

Ce n'est pas parce que tu passes dans la méthode OnPaint que tout est redessiné... en fait seule la partie invalidée est réellement redessinée (la propriété ClipRectangle du PaintEventArgs)
Enfin, je ne suis pas tout à fait sûr de comment ça marche, mais quand je fait un Paint personnalisé, si j'invalide toute la zone à dessiner, il y a un "clignotement" de l'image parce que tout est rafraichi, alors que si seule une petite partie est invalidée, je n'ai pas ce clignotement : seule la zone invalidée est rafraichie. Pourtant je ne me préoccupe pas dans le code de savoir quelle est la zone invalidée, je suppose que c'est géré par le Framework ou par GDI+

En effet, hélas, dans les tests que j'ai fait, dans le cas précis, le ClipRectangle couvre l'entièreté de la form à chaque paint. Hélas.

Sperot51, ce que tu dis ne m'étonne pas vraiment.

Vois-tu le moyen d'empêcher le paint de la form ou du usercontrol tant que le dernier contrôle n'a pas été redessiné, par exemple lorsque usercontrol.Visible est passé à true.

**tomlev** · 31/08/2007, 01h17

j'espere que ces problèmes de perf sont résolus avec WPF, qui ne s'appuie pas sur les API Win32 et est supposé utiliser l'accélération matérielle...

**Pol63** · 31/08/2007, 08h11

j'espere aussi qu'avec wpf ca sera mieux, mais wpf ne fonctionnera que sur xp sp3 et vista
alors que .net 2 marche de w98 à server 2003 ...

enfin le peu que j'ai pu lire sur wpf ca me laiss penser que tous les controles graphiques seront les meme que .net 2 c'est juste des nouveaux objets 3d de présentation qui serait fait avec wpf

**neptune** · 31/08/2007, 09h45

Sperot, tu avoueras que 100 labels clignotants n'est pas un modèle de design pour une application...

**Pol63** · 31/08/2007, 09h47

c'est à dire ?

je travaille sur une appli industrielle ... qui en plus peut etre multiécran ... et sous vb6 il n'y avait aucun problème

de toute facon, meme un seul datagridview que je deplace avec un timer, le truc il saccade à fond dès qu'il passe par dessus un autre objet ..., et encore plus quand il est rempli
et ce avec une carte graphique nvidia quaddro quelque chose soit disant pro developpement

**neptune** · 31/08/2007, 09h54

Je serait curieux de voir à quoi ressemble ton appli alors. Mais j'imagine mal un gars controller 100 labels clignotants toute la journée. Qu'en penses la médecine du travail? :-)

**Pol63** · 31/08/2007, 09h58

avant que l'informatique existe c'était des schemas eletroniques sur des armoires electriques avec plein de petit voyants qui clignotaient ^^

enfin c'est des images qui clignotent, ou qui change de couleur etc...

**theMonz31** · 31/08/2007, 11h53

salut

enfin, perso, tous ces problèmes sont souvent revelateurs,non pas forcement
d'une mauvaise méthode de programmation ni meme d'architecture, mais simplement d'un système informatique... qui nous amene bien souvent à faire un peu de la bidouille...

En soit, afficher 100 labels, c'est pas grand chose.. Par contre, le soucis
vient souvent de l'information à afficher...

L'obtention de l'information à mettre dans le label est-elle rapide ?
Est-il pertinent d'utiliser bcp d'image ? et si c'est le cas, peut-etre serait-il
plus judicieux d'avoir 1 unique controle qui fait 100 DrawImage() dans son
OnPaint() plutot que 100 PictureBox, ou label, ou bouton ?

J'ai souvent constaté sous windows que l'accumulation de controle (souvent
du meme type pour afficher une information) amenait des problèmes de rafraichissement... CE qui est logique.. Car chaque controle va devoir se
dessiner lui-meme... avec son contexte graphique, etc... Et on a beau dire,
ca ne peut que faire ramer les choses....

Enfin voila..

Petite intervention legèrement HS peut-etre... mais bon

The Monz, Toulouse

**Pol63** · 31/08/2007, 12h06

je persiste en disant que sous vb6 ca marchait très bien ...
mais de toute facon vous inquiétez pas pour moi, je suis passé par des buffered graphics, microsoft ne voulant pas son travail comme il faut, ca m'a donné plus de boulot

parce que n'aller pas me croire qu'avec 3GHz ce n'est pas faisable d'avoir 100 malheureux controles sur une feuille surtout qu'un mem pc arrive à gérer des milliers de robots qui se tire dessus en 3d !

et puis si le client a 100 machines, ce n'est pas qui irait lui dire que je vais lui en mettre que 10 sur l'écran !

autre chose, le datagridview, moi je lui passe une requete qui retourne 30000 lignes, il mets 25secondes à etre utilisable
là encore j'ai redéveloppé un datagrid hérité du datagridview et il est utilisable de suite et se charge en 7s
n'allez pas me dire à nouveau que je suis plus intelligent que les développeurs de microsoft

**theMonz31** · 31/08/2007, 12h34

autre chose, le datagridview, moi je lui passe une requete qui retourne 30000 lignes, il mets 25secondes à etre utilisable
là encore j'ai redéveloppé un datagrid hérité du datagridview et il est utilisable de suite et se charge en 7s
n'allez pas me dire à nouveau que je suis plus intelligent que les développeurs de microsoft

Beh peut-etre que si justement...

Moi, je ne pense pas que les meilleurs developpeurs soient TOUS chez Microsoft... donc, du moment que le truc il marche, Microsoft n'a pas forcement la volonté de l'excellence technique... sinon, ca se saurait...

Mais faut avouer que sur l'aspect Performance gdi et gdi+ ne sont pas des
foudres de guerre... mais comme pour la plupart des applications, cela est suffisant... il se contente de cela

The Monz, Toulouse

PS : Par curiosité, pour passer de 25 à 7 secondes, comment as tu fait ? (je veux dire, si tu peux en dire plus que juste surcharge...)

**neptune** · 31/08/2007, 13h02

Envoyé par theMonz31

PS : Par curiosité, pour passer de 25 à 7 secondes, comment as tu fait ? (je veux dire, si tu peux en dire plus que juste surcharge...)

Et de publier cette soluce sur CodePlex rapidement. Un DataGridView 3x plus rapide ca doit intéressé beaucoup de monde.

**Pol63** · 31/08/2007, 13h16

j'ai suivi un peu l'aide de microsoft en fait lol
il disent quand il y a beaucoup de de données le datagrid est lent et qu'il faut utiliser virtual mode
ensuite je charge les données dans un dataview dans un thread asynchrone et sur le thread principal un timer se charge de faire apparaitre le bon nombre de ligne

rien d'extra ordinaire vous voyez, c'est juste que d'ajouter les lignes dans une boucle le datagridview fait une pluie evenementielle surement pour se rafraichir pour rien

**SaumonAgile** · 31/08/2007, 15h21

Envoyé par sperot51

j'ai suivi un peu l'aide de microsoft en fait lol

C'est amusant comme le discours change quand on demande l'explication...

On passe de "j'ai redéveloppé un datagrid" à "j'ai suivi un peu l'aide de microsoft".

Les lignes qui suivent ne visent personne en particulier.
Il semblerait donc que Microsoft pense aussi aux performances. On en revient toujours à la même problèmatique, les développeurs ne savent pas gérer les gros volumes de données, et comme d'habitude, ils blament Microsoft pour leur incompétence.
Car on pourra me dire tout ce qu'on veut, ajouter 100+ controles sur un formulaire, ça relève déjà d'un certain manque de conception, c'est une pure hérésie ergonomique.

En ce qui concerne le problème, je rejoints la réponse de tomlev.

**Pol63** · 31/08/2007, 15h29

Envoyé par SaumonAgile

C'est amusant comme le discours change quand on demande l'explication...

On passe de "j'ai redéveloppé un datagrid" à "j'ai suivi un peu l'aide de microsoft".

Les lignes qui suivent ne visent personne en particulier.
Il semblerait donc que Microsoft pense aussi aux performances. On en revient toujours à la même problèmatique, les développeurs ne savent pas gérer les gros volumes de données, et comme d'habitude, ils blament Microsoft pour leur incompétence.

bien oui, car le datagridque j'ai fait je pourrais le diffuser il est utilisable, alors pourquoi microsoft n'en a pas fait un comme ca !!!

Car on pourra me dire tout ce qu'on veut, ajouter 100+ controles sur un formulaire, ça relève déjà d'un certain manque de conception, c'est une pure hérésie ergonomique.

En ce qui concerne le problème, je rejoints la réponse de tomlev.

ne jugez pas sans connaitre, et sur excel il n'y a pas des dizaines de boutons et de cases peut etre ???
excel ne pourrait pas etre développé en .net ! ca serait uen catastrophe
l'appli sur laquelle je developpe a besoin de ca, je peux rien y faire moi

**SaumonAgile** · 31/08/2007, 15h35

Envoyé par sperot51

ne jugez pas sans connaitre, et sur excel il n'y a pas des dizaines de boutons et de cases peut etre ???
excel ne pourrait pas etre développé en .net ! ca serait uen catastrophe
l'appli sur laquelle je developpe a besoin de ca, je peux rien y faire moi

Tu n'as pas lu cette ligne :

Envoyé par Moi

Les lignes qui suivent ne visent personne en particulier.

Et pour excel, ce n'est pas une aggrégation de textbox

, ne mélange pas tout.
Il existe des composants .NET proposant une partie non négligeable des fonctionnalités Excel (le Spread de chez FarPoint par exemple), c'est donc possible.

**Pol63** · 31/08/2007, 15h44

Envoyé par SaumonAgile

de chez FarPoint

donc pas dans le framework ...
parce que moi aussi je peux faire des composants fiables et rapide en repartant de control en overridant ce qui ralenti

enfin je suis pas d'accord avec toi de toute facon ^^

autre truc louche, j'ai une feuille avec 2 boutons, 3 images et un fond non uni (ca y est j'ai laché le mot)
au moment de faire .show, on voit la fenetre se construire pendant une bonne demie seconde, ca fait affreux
j'ai trouvé une bidouille de faire .opacit = 0 / .show / .opacity = 1 et ca apparait instantanément, mais ce framework est quand meme très lent graphiquement, c'est une abération

Eviter les nombreux appels à OnPaint dûs au nombre de contrôles présents sur le form

Windows Forms

Discussions similaires

Partager

Partager