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:

Zitat von Bernhard Geyer (Beitrag 1118732)

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.

[Tryer]

Ist Panel.AutoSize vielleicht True? Das würde bei jeder Inhaltsänderung ggf. ein Resize auslösen und damit die Neuberechnung?

Grüsse, Dirk

[QuickAndDirty]

Ich habe die Erfahrung gemacht das TMS einfach langsam zeichnet...wenn man mal die TAdvButtons nimmt...oder TShader oder TadvGrid die können einfach zu viel Feuerwerk....und die werden in Massen dann wirklich sehr sichtbar hintereinander gezeichnet....
Ist eben nur GDI+
Die Verhalten sich auf starren masken dann auch einfach besser als auf resizeable Forms!

[cookie22]

Zitat:

Zitat von weisswe (Beitrag 1118725)

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

Delphi-Quellcode:

AlphaBlend := True;

und

Delphi-Quellcode:

AlpahaBlendvalue = 0;

zu zeichnen und setz es dann auf

Delphi-Quellcode:

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

[hoika]

Hallo,

ich würde es erst einmal mit normalen TButtons versuchen.
Und ist es immer noch zu langsam, ein Panel und selbermalen.
Viell. geht ja auch ein TDrawGrid, kommt auf die Sitzpositionen an.


Heiko

[FredlFesl]

Liegts vielleicht an der lahmen Grafikkarte?
1,5s ist doch schon sehr happig. Ich bezweifle, das ein TDrawGrid hier großartig Abhilfe schaffen würde.

[Neumann]

Habe die gleiche Erfahrung mit den TMS-Buttons gemacht. Habe Panels mit bis zu 200 Buttons für Touchoberfläche und muss mit Anwendern mit sehr schwacher Hardware rechnen.
Bei einer größeren Zahl TMSSmoothButtons auf einem Panel bzw. auf einer Seite eines Pagecontrols bauen sie sich sehr langsam auf, wenn die Seite sichtbar gemacht wird uns sind deshalb leider für mich nicht brauchbar.

Verwende jetzt andere (TcyADVSpeedButtons) die von der Optik ebenfalls sehr gut und flexibel sind, aber wesentlich schneller gezeichnet werden.

Ein weiteres Problem ist wohl auch die dynamische Erstellung. Anscheinend braucht create viel Zeit. Es scheint besser zu sein, beim Programmstart einen Vorrat (z.B. Array 1..100 of txbtn) anzulegen und dies dann später sichtbar/unsichtbar schalten, zu beschriften oder zu verschieben usw.

[jaenicke]

Zitat:

Zitat von Neumann (Beitrag 1118766)

Ein weiteres Problem ist wohl auch die dynamische Erstellung. Anscheinend braucht create viel Zeit.

Naja, es werden halt alle (?) anderen Komponenten per Notify informiert, je mehr das sind, desto länger dauert es.

[Sir Rufo]

Zitat:

Zitat von jaenicke (Beitrag 1118783)

Zitat:

Zitat von Neumann (Beitrag 1118766)

Ein weiteres Problem ist wohl auch die dynamische Erstellung. Anscheinend braucht create viel Zeit.

Naja, es werden halt alle (?) anderen Komponenten per Notify informiert, je mehr das sind, desto länger dauert es.

So isses und darum sollte man bei so einer grossen Anzahl das in einer eigenen Komponente selber zeichnen oder als Image auf den Bildschirm klatschen. (@jaenicke hattest du ja auch schon vorgeschlagen)

Auch die Erstellung von mehreren stinknormalen Buttons (Button) dauert seine Zeit und man kann beim Aufbau zuschauen.
Ist jetzt noch ein langsamer Rechner/GraKa im Spiel, dann wird das nicht witzig.

Wenn das für einen Kinosaal sein soll, dann sprechen wir ja mal locker von 100-800 Buttons

[mkinzler]

dafür würde ich eh keine Buttons nehmen

[DeddyH]

Wenn es gar nicht anders geht und es unbedingt Einzelkomponenten sein müssen, dann kann es schon etwas bringen, diese nach Möglichkeit von TGraphicControl abzuleiten. Man muss dann halt auf ein Handle verzichten.

[Neumann]

Ich hätte da etwas, ist von mir von der freien Komponente tSimplegraph abgeleitet. Damit kann man einfach zur Laufzeit Pläne mit Komponenten erstellen, die auf Anklicken reagieren. Identifizieren kann man die Objekte in dem Control einfach über den Tag-Wert, den man auch zur Laufzeit setzen kann. Die Pläne lassen sich speichern und laden und das ist absolut schnell.

Die Objekte können in Form, Farbe Hintergrundbilder usw. frei gestaltet werden.

[mschaefer]

Moin, das Create und Notify ist als Zeitfresser schon ausgemacht. Damit sehe ich folgendes:

- Speed-Buttons sind schneller aufgebaut als Normal-Buttons
- Sammlungen aus Buttons können created invisible auf Position 0.0 vorgehalten werden.
- Das Panel mit den Buttons kann während des Aufbaus der Buttons auf invisible stehen.
- Das Panel mit den Buttons könnte bei Align-Top und Höhe 0 auf Align - Client geschaltet werden.
- Ein Image nehmen und bei Mouse-Click die Click-Position abfragen.
- Die Graph-Variante von Neumann klingt spannend.

Grüße in die Runde

[DeddyH]

Zitat:

Zitat von mschaefer (Beitrag 1118837)

- Speed-Buttons sind schneller aufgebaut als Normal-Buttons

Zitat:

Delphi-Quellcode:

TSpeedButton = class(TGraphicControl)

Zitat:

Zitat von DeddyH (Beitrag 1118819)

Wenn es gar nicht anders geht und es unbedingt Einzelkomponenten sein müssen, dann kann es schon etwas bringen, diese nach Möglichkeit von TGraphicControl abzuleiten.

*Hihi*

[Bummi]

wie wäre es mit sowas, nur als Anregung ....

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, ExtCtrls;

type
  TPlatzrecord=Record
    x:Integer;
    y:Integer;
    b:Double;
    h:Double;
    farbe:TColor;
    Nr:Integer;
  End;

  TPlatzrecordArray=Array of TPlatzrecord;

  TForm1 = class(TForm)
    Button1: TButton;
    PaintBox1: TPaintBox;
    procedure Button1Click(Sender: TObject);
    procedure PaintBox1Paint(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    FPlatzrecordArray:TPlatzrecordArray;
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation
const
 cColor:Array [0..9] of TColor=(clred,clBlue,cllime,clYellow,clmaroon,clSilver,clGray,clNavy,clBlack,clWhite);

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
var
  x,y:Integer;
begin
    SetLength(FPlatzrecordArray,200);
    for x := 0 to 9 do
    for y := 0 to 19 do
      begin
      FPlatzrecordArray[y*10 + x].x := x;
      FPlatzrecordArray[y*10 + x].y := y;
      FPlatzrecordArray[y*10 + x].nr := y*10 + x;
      FPlatzrecordArray[y*10 + x].h  := 0.8;
      FPlatzrecordArray[y*10 + x].b  := 0.7;
      FPlatzrecordArray[y*10 + x].Farbe  := cColor[y div 2];
      end;
    PaintBox1.Invalidate;
end;

procedure TForm1.PaintBox1Paint(Sender: TObject);
var
  scale:Double;
  x,y:Integer;
  c:TCanvas;
  r:TRect;
begin
  if High(FPlatzrecordArray)<>199 then Exit;

  Scale := paintBox1.Width / 20;
  if paintBox1.height / 20 < Scale  then Scale := paintBox1.height / 20;
  c := PaintBox1.Canvas;
    for x := 0 to 9 do
    for y := 0 to 19 do
      begin
      r.Left := round(FPlatzrecordArray[y*10 + x].x * scale);
      r.Top := round(FPlatzrecordArray[y*10 + x].y * scale);
      r.Right := r.Left + round(FPlatzrecordArray[y*10 + x].b * scale);
      r.Bottom := r.Top + round(FPlatzrecordArray[y*10 + x].h * scale);
      c.Brush.Color := FPlatzrecordArray[y*10 + x].Farbe;
      c.FillRect(r);
      c.Rectangle(r.Left,r.Top,r.Right,r.Bottom);
      c.TextOut(r.Left + (r.Right - r.Left - c.TextWidth(IntToStr(FPlatzrecordArray[y*10 + x].nr))) div 2,
                r.top + (r.bottom - r.top - c.TextHeight(IntToStr(FPlatzrecordArray[y*10 + x].nr))) div 2,
                IntToStr(FPlatzrecordArray[y*10 + x].nr));

      end;



end;

end.

[jaenicke]

Zitat:

Zitat von Bummi (Beitrag 1118854)

wie wäre es mit sowas, nur als Anregung ....

Ziemlich genau das (aber mit komplizierterer Berechnung der Positionen) ist es ja was ich in dem Link mache, nur dass es dort bereits ein komplettes Programm ist. ;-)

Zitat:

Zitat von jaenicke (Beitrag 1118761)

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

[Memo]

Zitat:

Zitat von weisswe (Beitrag 1118713)

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.

Ich hatte das Problem auch schonmal. Mir hat damals ein Tipp in einem anderem Forum geholfen:

Delphi-Quellcode:

try 
  SendMessage(Self.Handle, WM_SETREDRAW, 0, 0); 

  DoWhateverYouWant(); 
finally 
  SendMessage(Self.Handle, WM_SETREDRAW, 1, 0); 
end;