VirtualTreeView - Wer hat die Weiterentwicklung übernommen

[Tegi]

@Madas
Benutzt du die aktuelle Version?
Das Autofitting war seit etwa 4.6.x, wenn ich mich recht erinnere langsam, da die Implementierung dummerweise nach dem ersten DoGetCellContentMargin versehentlich mittels WM_SETREDRAW das Zeichnen wieder erlaubte. Das habe ich aber in der 4.8.0 oder 4.8.1 gefixt.
Sowohl in synthetischen Tests, wie auch in Real-World-Applikationen ist die Leistung dadurch deutlich gestiegen.

Ansonsten arbeite ich inzwischen in der Freizeit, so mir welche bleibt :-), an einem Footer. Den Vista-Code habe ich bereits überarbeitet; wenn der Footer fertig ist, kommt das mit.

[OG Karotte]

Zitat:

Zitat von Tegi

Ansonsten arbeite ich inzwischen in der Freizeit, so mir welche bleibt :-), an einem Footer. Den Vista-Code habe ich bereits überarbeitet; wenn der Footer fertig ist, kommt das mit.

Super :thumb:

[sh17]

Zitat:

Zitat von Tegi

Ansonsten arbeite ich inzwischen in der Freizeit, so mir welche bleibt :-), an einem Footer. Den Vista-Code habe ich bereits überarbeitet; wenn der Footer fertig ist, kommt das mit.

Schön ;-)

Schon irgend eine Meinung, wo man ggf. neue Demos unterbringen könnte?

[madas]

Zitat:

Zitat von Tegi

@Madas
Benutzt du die aktuelle Version?
Das Autofitting war seit etwa 4.6.x, wenn ich mich recht erinnere langsam, da die Implementierung dummerweise nach dem ersten DoGetCellContentMargin versehentlich mittels WM_SETREDRAW das Zeichnen wieder erlaubte. Das habe ich aber in der 4.8.0 oder 4.8.1 gefixt.
Sowohl in synthetischen Tests, wie auch in Real-World-Applikationen ist die Leistung dadurch deutlich gestiegen.

Also wir haben es mit der 4.7.0 und 4.8.5 getestet gehabt. Und da war es extrem langsam.
WM_SETREDRAW wird in der VirtualTree.pas genau dreimal aufgerufen. In unserer aktuellen Version (4.7.0)
und in der 4.8.5 passiert dies genau so oft und an den gleichen Stellen. Einzige Änderung die an den
Stellen hinzukam ist (FUpdateCount = 0). Was aber keine Auswirkung hat.

Damit Ihr das Ganze auch mal nachvollziehen könnt, ist im Anhang ein kleines Testprojekt mit "nur" 10000 Knoten (Zeit für Resize wird gestoppt). Ist onBeforeCellPaint als Event registriert dann dauert das Optimieren einer Spalte (unter WinXp) knapp 8s . Ohne onBeforeCellPaint nur 300ms.

Das Projekt wurde unter D2009 erstellt und die Version vom VST ist 4.8.5 .

[pertzschc]

Zitat:

Zitat von madas

Damit Ihr das Ganze auch mal nachvollziehen könnt, ist im Anhang ein kleines Testprojekt mit "nur" 10000 Knoten (Zeit für Resize wird gestoppt). Ist onBeforeCellPaint als Event registriert dann dauert das Optimieren einer Spalte (unter WinXp) knapp 8s . Ohne onBeforeCellPaint nur 300ms.

Ich habe mir den Quellcode des Beispieles mal angeschaut und folgende Frage zu meinem Verständnis:

Delphi-Quellcode:

procedure TForm1.VirtualStringTree1BeforeCellPaint(Sender: TBaseVirtualTree;
  TargetCanvas: TCanvas; Node: PVirtualNode; Column: TColumnIndex;
  CellPaintMode: TVTCellPaintMode; CellRect: TRect; var ContentRect: TRect);
var
  CachedShadowColor: TColor;
begin
  if (CellPaintMode = cpmPaint) then
  begin
    CachedShadowColor := TargetCanvas.Brush.Color;
    try
      if (Odd(Node.Index)) then
      begin
        TargetCanvas.Brush.Color := RGB(225, 225, 225);
        TargetCanvas.FillRect(CellRect);
      end;
    finally
      TargetCanvas.Brush.Color := CachedShadowColor;
    end;
  end;
  inherited;
end;

das wird von Euch nur dazu benutzt, um jede 2. Zeile anders einzufärben?

Wir machen das in einem anderen Event:

Delphi-Quellcode:

procedure TForm1.VST_HostListBeforeItemErase(Sender: TBaseVirtualTree;
  TargetCanvas: TCanvas; Node: PVirtualNode; ItemRect: TRect;
  var ItemColor: TColor; var EraseAction: TItemEraseAction);
begin
  if Odd(Node.Index) then begin
    ItemColor := col_VST_Line2; // auch TColor($F4F2F2);
  end
  else begin
    ItemColor := col_VST_Line1;
  end;
  EraseAction := eaColor;
end;

und haben derartige Probleme mit Version 4.7.0 noch nicht beobachtet.

Gruß,
Christoph

[madas]

Naja wozu sollte OnBeforeCellPaint denn deiner Meinung nach sonst zuständig sein, wenn nicht zum anpassen
vom bestimmten Sachen vor dem Zeichnen?

Btw: Du kannst die komplette Procedure auch leer lassen, bis auf das "inherited;". Selbst dann dauert
es ewig.

Wie gesagt bei den Versionen vor 4.6.x lief das Ganze ja auch noch ohne Probleme. Jetzt nicht mehr.

[pertzschc]

Zitat:

Zitat von madas

Naja wozu sollte OnBeforeCellPaint denn deiner Meinung nach sonst zuständig sein, wenn nicht zum anpassen
vom bestimmten Sachen vor dem Zeichnen?

Schau mal dazu in die VTV-Doku, Stichwort: Paint cycles and stages.

Zitat:

Zitat von madas

Btw: Du kannst die komplette Procedure auch leer lassen, bis auf das "inherited;". Selbst dann dauert
es ewig.

Auch hierzu gibt es in der Doku eine mögliche Erklärung:

Zitat:

before cell paint:
This paint stage is the first of the cell specific stages used to customize a single cell of a node and is called several times per node, depending on the number of columns. If no columns are used then it is called once.

Gruß,
Christoph

[madas]

Zitat:

Zitat von pertzschc

Zitat:

Zitat von madas

Naja wozu sollte OnBeforeCellPaint denn deiner Meinung nach sonst zuständig sein, wenn nicht zum anpassen
vom bestimmten Sachen vor dem Zeichnen?

Schau mal dazu in die VTV-Doku, Stichwort: Paint cycles and stages.

Zitat:

Zitat von madas

Btw: Du kannst die komplette Procedure auch leer lassen, bis auf das "inherited;". Selbst dann dauert
es ewig.

Auch hierzu gibt es in der Doku eine mögliche Erklärung:

Zitat:

before cell paint:
This paint stage is the first of the cell specific stages used to customize a single cell of a node and is called several times per node, depending on the number of columns. If no columns are used then it is called once.

Gruß,
Christoph

Ist ja alles schön und gut. Und es sei mal dahin gestellt, ob unsere Anpassungen an richtiger Stelle gemacht werden oder nicht (Dieser Event wird nicht nur dafür benutzt, um jede gerade bzw. ungerade Zeile anders einzufärben, sondern auch einzelnen Zellen eine bestimmte Farbe zu geben. Und da scheint mir (uns) dies der richtige Event dafür zu sein).
Trotzdem kann es meiner Meinung nach nicht sein, dass ein registrierter Event, dessen Eventhandler praktisch nichts macht, die Performance so in den Keller
zieht.

Aber vielleicht habe ich da auch einen Denkfehler. :gruebel:

[pertzschc]

Zitat:

Zitat von madas

Trotzdem kann es meiner Meinung nach nicht sein, dass ein registrierter Event, dessen Eventhandler praktisch nichts macht, die Performance so in den Keller zieht. Aber vielleicht habe ich da auch einen Denkfehler. :gruebel:

Lass uns doch nochmal nachfragen: warum rufst Du in der procedure eigentlich inherited; auf? Habe das bei den Beispielen hier im Forum noch nicht gesehen und selber auch noch nie so programmiert.

Gruß,
Christoph

[madas]

Zitat:

Zitat von pertzschc

Zitat:

Zitat von madas

Trotzdem kann es meiner Meinung nach nicht sein, dass ein registrierter Event, dessen Eventhandler praktisch nichts macht, die Performance so in den Keller zieht. Aber vielleicht habe ich da auch einen Denkfehler. :gruebel:

Lass uns doch nochmal nachfragen: warum rufst Du in der procedure eigentlich inherited; auf? Habe das bei den Beispielen hier im Forum noch nicht gesehen und selber auch noch nie so programmiert.

Gruß,
Christoph

Das ist noch ein Überbleibsel von unserer abgeleiteten Komponente. Wenn man nur ein normales VST benutzt, dann braucht das dort nicht hin. Aber selbst beim leeren Eventhandler dauert die Optimierung nun mal lange.

@pertzschc: Du scheinst ja das Beispiel runtergeladen zu haben. Dann leere doch Spaßes halber das OnBeforeCellPaint (kommentiere alles aus). Setze den RootNodeCount auf 100000. Dann siehst du was wir meinen.