Delphi - pomale zobrazovanie...
Mam taky maly problem. V databaze mam vyse 250 roznych produktov a k nim kratky popis. Kazdy produkt sa vytvara na dynamickom panely, ktory si vytvorim pred zobrazenim daneho produktu. Na tom panely sa mi vytvara asi 7 LABELOV, 1 IMAGE a 1 RICHTEXT. Ked si dam zobrazit vsetky produkty, vsetkych cca 250 panelov sa mi okamzite vytvori ale kym sa zobrazia tak to trva aspon 50 sekund. Co som sa uz pytal viacerych programatorov, tak je to sposobene tym ze vlastne ja vytvaram naraz v jednom cykle 250 * 8 komponentov co je strasne vela a druha vec je, ze Windows sa pomale prekreslovanie. Osetril som to tak, ze si robim strankovanie, ale nie je to idealne, ale je to postacujuce. Mozno mi bude vediet niekto poradit, ako to urobit bez toho aby som nemusel pouzivat to strankovanie. DoubleBuffering mam zapnute, ale aj tak to ide pomaly... Nech robim, co robim ide to pomaly. Vytvara sa naraz vela komponentov. Dalsia vec je ze by som mohol pouzit fremy. Pomocou fremov by to islo rychlejsie? To znamena nie na panel, ale vytvorit si jeden frem a ten vytvarat dynamicky... Vdaka...
nevyznam sa sice v delphi, ale taketo veci by si mal robit cez thready na pozadi aby si to nenacitaval v jednom cykle naraz, zbytocne zatazujes hlavny proces. nepoznam sice moznosti delphi, ale urcite thready podporuje.
Samozrejme, ze podporuje. Krome psani ovladacu a pretypovavani operatoru (oblibeny argument ceckaru) v nem napises to same co v C - muzes vyuzivat bud primo WinAPI nebo jejich zapouzdreni ve VCL, coz je mnohem jednodussi a rychlejsi.
Problem je v tom, ze vytvari nejakych 2000 WinControls a to proste neni optimalni pristup. Druha vec je, ze na Win9x takovy program zrejme vubec nespusti...
Ale spustim... testoval som to aj na Win9x... a islo to celkom pekne...
Kontroloval jsi take sustemove prostredky ?
Pokud totiz klesnou nekam na 10%, zacnou se Windows chovat podivne...
A kdyz k tomu zapocitas IE, ktery je zere a nevraci, tak pak muzes hledat problem u programu, ktery jednou jde, podruhe jde taky, ale chova se divne a potreti se vubec nespusti.
Systemove prostriedky som nekontroloval, ale podla mna to bude v poriadku. Strankovanie mam urobene na 5 - 10 produktov na jednu stranku, co zaberie v pamati asi 6 MB. Po kazdom prepnuti stranky sa vsetky objekty zrusia a vytvoria sa nove s aktualnymi udajmi z danej stranky... Mozem este na Win9x pozrier systemove prostriedky...
Pokud to mas pres strankovani, pak je to OK. Ale psal, jsi, ze jsi proti strankovani a ze vytvaris 250x8 objektu...
Ono s tym ma mozno problem samotny windows, ked ma preratavat ca. 500*10=5000 okien (kazdy komponent, richbox, atd. je okno)
Alebo napr. ak si vytvoris len obycajny Windowsacky listbox a narves donho napr. 30000 poloziek bude to chvilu trvat (opozdenie vznika v samotnych Win, pri InsertItem(), resp. pri posielani insert item messages tomu listboxu).
Take veci sa daju robit efektivnejsie tak, ze si to clovek sam kresli - odpadava duplicita ukladania dat (t.j. udaje mam niekde v pamati programu, ale pre napr. ten listbox ich este musim vsetky nacpat aj do listboxu, co trva dlho), ak si to kreslim sam tak pouzivam stale len tie udaje v pamati, nemusim ich uz nikde cpat. Ale je to hodne narocne na naprogramovanie/vyvoj (musis urobit algoritmus ktory vie zobrazit akykolvek vysek z toho "okna" (zoznamu apod.), pri kazdom prijatom WM_PAINT message).
Ano, Widle tolik objektů nezvládnou v přijatelném čase. Narazil jsem na podobný problém. Dělal jsem program na album fotografiií (RceAlbum - 12.htm až dole). Původně byl každý náhled samostatné TImage. Mělo to sice výhodu, že nebylo nutno nikde více si obrázek pamatovat, ale už při 50 až 100 fotkách to bylo neúnosně pomalé. Pak jsem udělal TDrawGrid a vykresluju si fotky na vlastní triko a už je to svižné. Dokonce stíhám i načítat náhledy z TEMPů. Kolegovi Intexovi doporučuju též TDrawGrid a vykreslovat si to tam vše sám programově.
Raz som videl program robeny vo VisualBasicu v ktorom sa rvalo nejakych niekolko tisic poloziek do listboxu (nejaky zoznam suborov na viacerych CDckach), ale ked som tam klikol na novy zoznam (mali sa povodne udaje listboxu zrusit), tak to trvalo snad viac ako minutu
Neviem co s tym ten visualbasic minutu robil ked mal ten listbox len zrusit 
To je jednoduche, ne ? Odeberu olozku, seradim, odeberu polozku, seradim...
Podobny problem se resil na builderu, kdy to ten clovek radil pri vlozeni kazde polozky a stezoval si, ze mu nacitani trva dlouho...
Len tak na ukazku pridavam obrazok ako vyzera jeden panel.
Toto je panel, presne z programu. Takto si ich vytvaram na ScrollBoxe 5 - 10. Este neviem, ake bude vysledne cislo. Asi 10 panelov na jednu stranku... Takto to ide uplne bez problemov a necakam viac ako pol sekundy, kym sa zobrazia vsetky panely. Ked to bolo zobrazenie uplne vsetkeho, tak panely sa vytvorili hned. Akurat to zobrazenie trvalo velmi dlho... Windows ma pomale vykreslovanie. Mozno som zvolil nespravny postup, ale teraz ku koncu, ked je uz vsetko hotove, je zbytocne to vsetko prerabat...
Typ oceli: nerez
nemel by tam byt typ materialu ?
Ako je na stranke tak to musi byt aj v programe... Ja som si to nevymyslel...
To by sa krasne dalo urobit vlastnym vykreslovanim, alebo cez nejaky grid (ako pisal Rce vyssie), ptz. tam je vpodstate pevna vyska takze by sa dala pekne ratat momentalna pozicia.
No ale ked je to uz urobene tak to asi prerabat uz nebudes, to by bolo dost roboty.
Podla toho ako to spravanie popisujes mam pocit ze zaroven robi nieco tvoj program a zaroven aj vykresluje Win, a Win nema na vykreslovanie dost vykonu CPU, mozno nieco robis neefektivne ale to bez zdrojaku a debugovania tazko urcit takto na dialku. Tych 250*8 okien je dost, s tym Win maju co robit.
Presne tak. Zaroven sa robi vytvaranie objektov a zaroven to aj Win vykresluje. Nepomoze tu ani osetrenie sprav Win "Application.ProcessMessages" - prave naopak, este viac to spomalovalo. Aj napriek zapnutemu dvojitemu buferingu...