Performance Problem - viele VCL Komponenten!

[weisswe]

Habe das Problem, das beim (dynamischen) Zeichnen vieler VCL Komponenten (z.B. Buttons) der Aufbau sehr lange dauert.
Gibt es eine Möglichkeit im Hintergrund zu zeichnen? Hab schon einiges ausprobiert - z.B. LockWindowUpdate usw.
Leider ohne Erfolg. Komponenten werden beim Neuzeichenen (Skalieren sich automatisch bei Window Größenänderung) wieder nur "einzeln" langsam aufgebaut.

Vielleicht hat jemand eine gute Idee.

[stahli]

Hallo und herzlich willkommen erst einmal.

Was heißt viele Komonenten und was heißt lange?
Standardkomponenten oder Dritt-Kompos? (Werden vielleicht irgendwelche Ereignisse beim Zeichnen aufgerufen?)
Vielleicht mal einen Screenshot anhängen?

[mkinzler]

Die Controls werden einzeln gezeichnet, weil jedes Control sich selber zeichnet.

[weisswe]

Ok, werde mein Problem etwas kontreter beschreiben:
- Programm zeichnet Sitzplätze z.B. wie bei Kino-Reservierungen
- Größe/Form der Buttons je nach Panel-Größe - Vollbild
- Komponenten sind 3rd Party -> TMS

Ablauf:
- Filter auswählen (z.B. Saal)
- Holden der Daten aus DB, Datenarray füllen -> Mem
- Buttoneigenschaften setzen (Farbe, Nr, ...)
- "Einzelne" Buttons zeichnen -> Visible = True

Sogar auf meinem i7 siehst du wie jeder Button aufgebaut wird (komplett dauert ca. 1,5 sec).
Aber es soll auf einem Pentium XP Touchcomputer laufer - und - naja - da können es schon mehrere Sekungen dauern,
zumal ich ja keine CPU Power sonder Grafikpower benötige.

Es würde ja schon besser "aussehen", wenn man die einzelnen Button Aufbauzyklen nicht sehen würde.
Wie z.b.
+ Panel beginUpdate -> einfrieren
+ zeichne alle Komponenten
+ Panel endUpdate -> zeigen!

:-/

[mkinzler]

.BeginUpdate() friert die Controlls aber nur ein, d.h. es wird das Zeichnen verhindert. Bei .EndUpdate() werden dann automatisch neu gezeichnet.
Das ist sinnvoll um mehrfaches Zeichnen zu verhindern (z.B. bei Hinzufügen von Elementen)

[stahli]

Ich weiß zwar nicht, wie die TMS-Controls sich zeichnen, aber am zeichnen selbst wird die Zerzögerung sicher nicht liegen.

Wird da noch irgend etwas berechnet oder so? Im XE gibt es AQTime, um solche Aufrufe zu analysieren. Vielleicht kannst Du eine Trial nutzen o.ä.
Meine Verzögerung lag daran, dass ich Streamdaten immer wieder neu entpackt habe beim Zeichnen. Ich hatte auch nicht erwartet, dass das so viel ausmacht...

Falls Du verschachtelte Ausrichtungen (Align, Anchors) und dynamische Größenänderungen nutzt, könnte das evtl. auch eine Ursache sein.

[weisswe]

Wenn ich alle Controls INVISIBLE setze und dann alle wieder auf VISIBLE setze - hab ich schon das Problem, ohne irgendwelche Eingeschaften (Position, Größe, Farbe, ..) zu ändern.
Daraus schliesse ich, das es ein Zeichenproblem der Komponenten ist.

Habe auch schon einen Profiler über den Code gelegt (Zeitstempel). Da gibt es "keine" Performance-Probleme lauf Zeitmessung - selbst beim Zeichen aller Elemente - da - wenn alle Controls auf Visible in der Schleife gesetzt wurden - ja "parallel" bzw. danach der Bildschirmaufbau stattfindet - den ich ja nicht "kapseln" (stoppen) kann...

[Bernhard Geyer]

Schon mal probiert das Panel auf DoubleBuffered = True zu setzen? Hilft bei einigen Controls

[weisswe]

Zitat von Bernhard Geyer:

Schon mal probiert das Panel auf DoubleBuffered = True zu setzen? Hilft bei einigen Controls

Ja, hab ich

[stahli]

Werden die Controls vielleicht mehrfach hintereinander gezeichnet?
Vielleicht wäre ein Test mit EINEM Sitzplatz sinnvoll um den genauen Ablauf besser nachzuvollziehen.

Ich bleibe dabei: Das reine Zeichnen eines Controls (oder auch 100) wird nicht so lange dauern, dass man eine deutliche Verzögerung bemerkt.
Ich habe in einem Projekt mal intensiv Alpha-Skins dynamisch eingesetzt. Das brachte dann schon eine Verzögerung, aber dabei sind ja wirklich komplexe Hintergründe zu berechnen.