C++ Winforms : PB Affichage lent d'un panel de 50 boutons
sebsebz
Messages postés
1
Date d'inscription
mardi 22 mai 2007
Statut
Membre
Dernière intervention
18 septembre 2008
-
18 sept. 2008 à 10:11
cs_rt15 Messages postés 3874 Date d'inscription mardi 8 mars 2005 Statut Modérateur Dernière intervention 7 novembre 2014 - 19 sept. 2008 à 14:11
cs_rt15 Messages postés 3874 Date d'inscription mardi 8 mars 2005 Statut Modérateur Dernière intervention 7 novembre 2014 - 19 sept. 2008 à 14:11
1 réponse
cs_rt15
Messages postés
3874
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
7 novembre 2014
13
19 sept. 2008 à 14:11
19 sept. 2008 à 14:11
Bienvenue !
Bon par contre, tu n'as pas de chance de tomber sur moi pour une première réponse : tu vas avoir droit à un bon troll...
Tu fais du C++/.NET, aussi appelé C++/CLI. Autrement dit tu code en C++. Mais quand tu compiles, au lieu de produire du langage machine directement compréhensible par ton processeur (Comme c'est le cas avec du C++ classique), tu produis du code intermédiaire.
Ce code intermédiaire, baptisé MSIL, datant en gros de 2002, ne peut être exécuté que par une machine virtuelle (La CLR), comme celle du fort connu Java.
Donc, pour que ton programme puisse être exécuté sur un PC quelconque, il faut qu'une machine virtuelle soit présente. Donc soit il faut prier pour qu'elle y soit déjà, soit il faut l'installer en même temps que ton logiciel, d'une manière ou d'une autre.
Non seulement il te faut une machine virtuelle, mais il faut en plus qu'elle soit en état d'exécuter ton application. Une application compilée en .NET 2.0 ne tourne pas sur une CLR 1.1. Normal. Mais qu'une application compilée en .NET 1.1 ne tourne pas sur une CLR 2.0, c'est quand même hallucinant. Partit comme ça, on va se retrouver avec une foultitude de CLR sur nos PCs.
Sous Windows, la couche qui permet à un .exe classique d'être exécuté sur les différentes versions est appelée Win32. Cette couche est composé d'un ensemble de dll proposant des fonctions que les .exe sont sûrs de trouver sur le PC où ils sont exécutés. La couche Win32 propose toutes les fonctionnalités de base : allocation, accès aux fichiers, création de fenêtres... Tout le reste s'appuie sur ces fonctions (malloc, fprintf, les streams C++...)
Comme le reste donc, le dotnet s'appuie sur le Win32. Et l'odeur du Win32 est tellement présente dans les classes .NET (Handle de fenêtre, device context...) que l'on peut se demander comment Microsoft peut ne serait ce que prétendre que le dotnet est indépendant de la plateforme.
Côté rapidité, tu trouveras des articles vantant la qualité de la CLR, souvent considérée comme plus rapide que son équivalente Java. Comme pour le Java, la CLR n'interprète pas le langage intermédiaire. Elle fait de la compilation JIT, autrement dit, le code intermédiaire est compilé par paquet en code machine compréhensible par le processeur. Ce système est franchement opaque, et il faut une certaine expérience pour aller se faire une idée du code machine généré. Mais je peux te dire que c'est pas beau à voir.
Sans aller jusqu'à regarder le langage machine produit, on peut être tenté de faire des benchs. Mais il ne faut pas oublier un point fondamental lors de la réalisation de benchs sur le dotnet : Le dotnet s'appuie sur le Win32. Par exemple, si on chronomètre une ouverture de fichier... La CLR appelle CreateFile. CreateFile a un boulot monstrueux à réaliser. Bilan, on va trouver le dotnet au moins 90 % aussi rapide que du pur Win32 sur une ouverture de fichier. Car peut être 95% du code exécuté le sera en Win32. On ne verra pas que les 5% de dotnet se sont trainés lamentablement.
Ce qu'il faudrait tester, c'est un Windows entièrement en dotnet et voir comment ça tourne.
Ah pardon. Il est impossible de faire un système d'exploitation en dotnet. Il faudrait au moins une machine virtuelle en langage machine pour qu'il puisse s'exécuter.
Ce qui est à gerber, c'est la différence de consommation de ressources mémoire entre un helloworld en dotnet et un helloworld classique. Et je parles même pas du nombre de threads... M'enfin l'écart est sensé se réduire avec l'augmentation de la taille de l'application.
Le fait que les applications dotnet soient exécutées par une machine virtuelle est parfois présenté comme un avantage, car cela rend l'application indépendant de la plateforme matérielle. Il y a d'ailleur une implémentation Linux, mono, qui vivote. Mais on devient dépendant de la machine virtuelle, alors ou est l'intérêt ?
Tu peux penser : le dotnet, c'est l'avenir, car Microsoft l'a dit. Mais regarde sur ton PC. Tu as probablement plus d'une quarantaine de processus en train de tourner. Combien sont en dotnet ? 2 ? 1 ? 0 ? Pourquoi crois-tu que Word n'est pas en dotnet ?
Le dotnet est l'avenir. Mais cela ne me surprendrait pas que le Win32 lui survive.
<hr />
Ah oui au fait. Pour ton problème.
Tu supposes que pour parler comme ça, je n'ai jamais fait de dotnet.
Bin si, j'ai quand même un minimum de C# à mon actif.
Mais pas assez pour t'aider, il est vrai.
Tout ce que je peux te proposer c'est de générer tous tes boutons dans un Panel invisible (Si c'est possible : je ne peut pas voir tes screens).
Puis de rendre visible ce panel.
monPanel.Visible = false;
// J'ajoute mes boutons dans monPanel
monPanel.Visible = true;
Bon par contre, tu n'as pas de chance de tomber sur moi pour une première réponse : tu vas avoir droit à un bon troll...
Tu fais du C++/.NET, aussi appelé C++/CLI. Autrement dit tu code en C++. Mais quand tu compiles, au lieu de produire du langage machine directement compréhensible par ton processeur (Comme c'est le cas avec du C++ classique), tu produis du code intermédiaire.
Ce code intermédiaire, baptisé MSIL, datant en gros de 2002, ne peut être exécuté que par une machine virtuelle (La CLR), comme celle du fort connu Java.
Donc, pour que ton programme puisse être exécuté sur un PC quelconque, il faut qu'une machine virtuelle soit présente. Donc soit il faut prier pour qu'elle y soit déjà, soit il faut l'installer en même temps que ton logiciel, d'une manière ou d'une autre.
Non seulement il te faut une machine virtuelle, mais il faut en plus qu'elle soit en état d'exécuter ton application. Une application compilée en .NET 2.0 ne tourne pas sur une CLR 1.1. Normal. Mais qu'une application compilée en .NET 1.1 ne tourne pas sur une CLR 2.0, c'est quand même hallucinant. Partit comme ça, on va se retrouver avec une foultitude de CLR sur nos PCs.
Sous Windows, la couche qui permet à un .exe classique d'être exécuté sur les différentes versions est appelée Win32. Cette couche est composé d'un ensemble de dll proposant des fonctions que les .exe sont sûrs de trouver sur le PC où ils sont exécutés. La couche Win32 propose toutes les fonctionnalités de base : allocation, accès aux fichiers, création de fenêtres... Tout le reste s'appuie sur ces fonctions (malloc, fprintf, les streams C++...)
Comme le reste donc, le dotnet s'appuie sur le Win32. Et l'odeur du Win32 est tellement présente dans les classes .NET (Handle de fenêtre, device context...) que l'on peut se demander comment Microsoft peut ne serait ce que prétendre que le dotnet est indépendant de la plateforme.
Côté rapidité, tu trouveras des articles vantant la qualité de la CLR, souvent considérée comme plus rapide que son équivalente Java. Comme pour le Java, la CLR n'interprète pas le langage intermédiaire. Elle fait de la compilation JIT, autrement dit, le code intermédiaire est compilé par paquet en code machine compréhensible par le processeur. Ce système est franchement opaque, et il faut une certaine expérience pour aller se faire une idée du code machine généré. Mais je peux te dire que c'est pas beau à voir.
Sans aller jusqu'à regarder le langage machine produit, on peut être tenté de faire des benchs. Mais il ne faut pas oublier un point fondamental lors de la réalisation de benchs sur le dotnet : Le dotnet s'appuie sur le Win32. Par exemple, si on chronomètre une ouverture de fichier... La CLR appelle CreateFile. CreateFile a un boulot monstrueux à réaliser. Bilan, on va trouver le dotnet au moins 90 % aussi rapide que du pur Win32 sur une ouverture de fichier. Car peut être 95% du code exécuté le sera en Win32. On ne verra pas que les 5% de dotnet se sont trainés lamentablement.
Ce qu'il faudrait tester, c'est un Windows entièrement en dotnet et voir comment ça tourne.
Ah pardon. Il est impossible de faire un système d'exploitation en dotnet. Il faudrait au moins une machine virtuelle en langage machine pour qu'il puisse s'exécuter.
Ce qui est à gerber, c'est la différence de consommation de ressources mémoire entre un helloworld en dotnet et un helloworld classique. Et je parles même pas du nombre de threads... M'enfin l'écart est sensé se réduire avec l'augmentation de la taille de l'application.
Le fait que les applications dotnet soient exécutées par une machine virtuelle est parfois présenté comme un avantage, car cela rend l'application indépendant de la plateforme matérielle. Il y a d'ailleur une implémentation Linux, mono, qui vivote. Mais on devient dépendant de la machine virtuelle, alors ou est l'intérêt ?
Tu peux penser : le dotnet, c'est l'avenir, car Microsoft l'a dit. Mais regarde sur ton PC. Tu as probablement plus d'une quarantaine de processus en train de tourner. Combien sont en dotnet ? 2 ? 1 ? 0 ? Pourquoi crois-tu que Word n'est pas en dotnet ?
Le dotnet est l'avenir. Mais cela ne me surprendrait pas que le Win32 lui survive.
<hr />
Ah oui au fait. Pour ton problème.
Tu supposes que pour parler comme ça, je n'ai jamais fait de dotnet.
Bin si, j'ai quand même un minimum de C# à mon actif.
Mais pas assez pour t'aider, il est vrai.
Tout ce que je peux te proposer c'est de générer tous tes boutons dans un Panel invisible (Si c'est possible : je ne peut pas voir tes screens).
Puis de rendre visible ce panel.
monPanel.Visible = false;
// J'ajoute mes boutons dans monPanel
monPanel.Visible = true;