Diskuze: Forms - WF
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
Zobrazeno 5 zpráv z 5.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
Nemyslím si, že počet "forms" by nějak měl ovlivňovat výkon. Výkon ovlivňuje samotný způsob práce s nimi a ne jejich počet. Podle toho, jak si naprogramuješ logiku fungování, budeš to mít rychlé, či pomalé...
Vzhledem k tomu, že vykreslování WinForm aplikací zpracovává procesor, tak čím víc věcí budeš vykreslovat, tím víc výkonu procesoru to vezme. Nevidím problém v tom, že bych měl zobrazených najednou, dejme tomu, 100 oken WinForm aplikací, které budou mít statická grafická data ( třeba text, obrázek), ale začni v každém z nich cyklicky vykreslovat nějaká grafická data (třeba graf real-time dat) a problém bude na světě. Jak je již psáno výše, vše záleží na tom, co dané okno dělá.
Nevím, zda se můj příspěvek primo týká dotazu, ale zkusme:
Kdysi (v dobách starých Pentií - řekněme takt 166 MHz) jsem si v Delphi
udělal apku, která obsahovala form, ten obsahoval scrolovatelný panel a ten
1000 editů (textbox). Start byl velice pomalý a ani scrolování nic moc. Tak
jsem to celé předělal na custom drawing a rychlost se zázračně našla.
Je jasné, že Borland BCL není WF, ale jistou paralelu jsem v tom našel.
Těžko říct, zdali to bude zajímat tazatele, ale tématu se to rozhodně
týká.
Ve WinForm aplikaci se to bude chovat úplně stejně, jak popisuješ. Ono
stačí použít jedno okno a jen nějaký ten graf, který překresluješ
párkrát za sekundu a hned uvidíš, jaký to bude slimák... Ale když to
začneš vykreslovat vlastnoručně pomocí třídy Graphics, tak to pofrčí
moc pěkně... Stejně tak s těmi ostatními komponentami. I když kreslit ty
komponenty ručně je strašná piplačka, tak na výsledném výkonu to bude
moc znát...
Zobrazeno 5 zpráv z 5.