backgroundimage sur mdi container

Bonsoir,

voila j'ai un problème. j'ai un formulaire mdi. j'aimerais affecter un background image à mon parent. le probleme est que l'affichage est lent, lorsque je fais un resize de ma form ou autre manipulation c'est une horreur. comment puis-je améliorer ça ?

mon backgroundimagelayout est valorisé à stretch !

j'ai abaisser la qualité et la résolution de mon image au maximum pour que ce soit le plus léger possible. mon image actuelle pèse 8ko et pourtant j'ai toujours autant de problèmes. pourriez-vous m'aider svp ? 8-)

merci ^^

windows forms ne permet pas de faire ca ^_^
une image en strech et/ou de la transparence et c'est la catastrophe

wpf permet de faire des applications jolies car ca utiliser directX pour le rendu et non pas un vielle dll d'il y a 15 ans

bonjour;

alors on peut dire que WPF et silverlight utilise la carte graphique pour affiche et actualise les interfaces par contre les winforms utilisent directement le processeur pour les intarfaces????? :calim2: :roll:

le texte qui va suivre n'est pas parfait et exhaustif, mais ce que j'en ai vu en creusant un peu


windows forms utilise gdiplus.dll, extension de gdi.dll (gdi doit dater de windows 95 je pense)

c'est une dll avec des fonctions graphiques qui repose sur une notion de parentée, de handle de fenetre et de rachissement légèrement exagéré (chaque control en .net possède un handle de fenetre ...)
le framework étant codé en .net, on peut regardé comment c'est fait, et certains contrôles font des rectangles, du texte et autre tout bêtement ...

par exemple sous windows xp tu déplaces une fenetre par dessus une autre, celle du dessous est appelée à se redéssiner (à base de traits, rectangles, cercles, texte) des centaines de fois pendant le déplacement (event paint appelé pour chaque controle en continu)
ou encore pour faire de la transparence en winforms, le controle transparent demande au controle parent de se déssiner sur lui (alors qu'il s'était déjà déssiné pour lui meme juste avant)
bref ca fait du bricolage pas performant

en wpf c'est directX qui est utilisé pour le rendu, donc des fonctions déjà plus réfléchies, et qui peuvent profiter de l'accélération graphique (ca peut aussi etre exécuté par le processeur si elle n'est pas puissante, mais ca reste quand meme plus performant que du windows forms)
et puis le rendu est plus élaboré, chaque controle ne se rafraichit pas sans raison ...


windows vista et 7 ont aussi apporté une gestion du bureau par directX et non pas gdiplus, l'exemple cité plus haut de la fenetre qui se déplace ne cause alors pas de rafraichissement ; une application windows forms y est alors plus performante que sur windows xp

merci pour vos réponses, je vais donc revoir mes exigences à la baisse ^^
je devrais étudier le wpf un jour, mais ça a l'air très complique le xaml ! :s

c'est comme tout, ca a l'air complexe vu de l'extérieur, mais une fois dedans ca se fait ...

et en fait plus on progresse en wpf, plus on trouve que c'est simple et puissant

mais biensur on ne devient pas à l'aise dessus en une semaine ...

dans ce cas je vais voir si le site propose des tuto vraiment complets sur le wpf...
je sais que la gestion du design est différente, mais c'est plutot le code qui m'inquiète. je suis déja entrain d'apprendre le c#3 avec le linq... alors changer radicalement du jour au lendemain ça me ferait mal ^^

wpf s'intègre bien avec les collections
le principe c'est qu'en c# tu te fais une collection d'objet, tu as tel listbox qu'il affiche cette collection
et en xaml tu expliques que tel classe tu veux l'afficher de telle manière (un label qui affiche la propriété machin, un bouton qui appelle telle sub de la classe etc...)
et au miracle, ton listbox est rempli, avec un visuel comme si tu avais fait un usercontrol, et en plus la modification sur l'interface modifie l'instance et réciproquement (et avec le type de collection qui va bien, un ajout dans la collection ajoute dans l'interface sans rien coder)

par contre des tutos complet j'en cherche encore ...