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

[cookie22]

Zitat von weisswe:

...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!

:-/

Versuch mal das Ganze mit AlphaBlend := True; und AlpahaBlendvalue = 0; zu zeichnen und setz es dann auf AlphaBlend := False; . Dann sollte zu mindest nicht zusehen sein, wie die Buttons gezeichnet werden.

[jaenicke]

Für den Anwendungszweck wäre es vielleicht sinnvoll die Komponenten selbst zu zeichnen. Eben ohne x separate Komponenten. Damit hatte ich selbst mit hunderten Elementen keinerlei Performanceprobleme.

Wie das geht siehst du hier, wenn auch dort (weil es nur ein Beispiel sein sollte) nicht sonderlich gut optimiert, insbesondere nicht was neue Features aktueller Delphiversionen angeht:
http://www.delphipraxis.net/901617-post.html