Immaginez avoir une application WinForms relativement complexe, et que les sirènes de WPF sont tellement attirantes, que vous voulez intégrer un contrôle WPF dans un formulaire quelque part perdu dans l'application. Le formulaire question est ouvert et fermé souvent.

La solution est de coder son contrôle WPF, puis de l'intégrer dans une application WinForms en utilisant ElementHost, ce petit bout de "magie" qui fait gagner bien du temps.

Rapidement, on constate que le chargement du contrôle WPF prend énormément de temps... Sur ma machine, un Core2 Duo 3Ghz, cela prend à chaque ouverture du formulaire quelque chose comme 3 à 4 secondes avant d'afficher proprement le formulaire qui contient le ElementHost. Et non content de ralentir le chargement du formulaire, l'affichage se faire par morceaux... Pas très fancy... Simple intuition, mais cela ressemble au chargement du runtime de WPF qui prend du temps...

La solution pour améliorer tout ca est relativement simple : Il suffit de garder un contrôle ElementHost "vide" visible en tout temps. Placer un contrôle de type ElementHost de taille 1x1 quelque part dans une fenêtre qui reste visible tout au long de l'exécution de l'application.

Le résultat, le formulaire s'affiche sans aucun délai ni problème visuel. Bien entendu, le chargement du formulaire "initial" qui contient le ElementHost vide prend du temps à charger au départ, mais cette fois ci le formulaire qui contient vraiment un contrôle WPF s'affiche instantanément, et sans bizarreries visuelles.

D'un point de vue plus technique, il semblerait que l'initialisation de WPF se fait lors de la création du premier ElementHost de l'application, puis se désinitialise lors de la fermeture du dernier ElementHost de l'application. Une petite analyse par réflector ne m'a pas montré l'existence d'une méthode "InitializeAndKeepWPFInitialized()", et il s'agit très probablement d'instancier un type de WPF pour initialiser proprement le tout... Mais créer une instance d'un ElementHost est amplement suffisant !