Einzelnen Beitrag anzeigen

Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
2.272 Beiträge
 
Delphi 10.4 Sydney
 
#4

AW: Grafikperformance von Virtual Treeview

  Alt 15. Mär 2019, 13:00
Ich benutze die VirtualTreeView Komponente auch in fast allen meinen Programmen und bin auch nicht gerade unerfahren mit der Komponente. Aber solch krasse Performance Probleme kenne ich gar nicht. Mein Tipp wäre ja gewesen, dass du da in einem Event etwas zeichnest, was wiederum etwas anderes übermalt und es deshalb zu einer Schleife kommt.
Die gleiche Denke hatte ich auch und nach sowas hab ich lange gesucht. Vergeblich. Irgendwann dann ein Testprogramm gemacht und darin mit einem Array of Array of String eine zweidimensionale Struktur geschaffen, Zufallsdaten rein und dann in OnGetText nur über den NodeIndex bzw. den ColumnIndex die Zeile und Spalte bestimmt. Absolutes Minimum. Ergebnis war Ruckelzuckel. Was mich ziemlich geschockt hat weil ich den VST seit vielen Jahren verwende (schon lange zu Mike Lischkes Zeiten) und er da immer flott war. Allerdings habe ich in den letzten Jahren auch nicht mehr auf die Grafik-Performance geachtet, weil Entwicklermaschine flott und Problem nicht zu erkennen. Daher kann ich nicht sagen ab welcher Version sich das evtl. eingeschlichen hat.

Allerdings habe ich auf meiner VM in der ich entwickele die Einstellung nicht geändert. Eventuell machen 128MB Grafikspeicher doch den entscheidenden Performanceverlust. Bei mir sind es die empfohlenen 1GB von VMWare (s. Screenshot). Als Grafikkarte habe ich eine GT630 verbaut (auch nicht die beste Karte). Aber keine Probleme.
Ich verwende VirtualBox und da kann ich nicht mehr als 256 MB Videospeicher definieren. Ok, dass die Intel-iGPUs nicht der Hit sind ist ja bekannt. In der Kombination mit VirtualBox schaukelt sich da evtl. auch was hoch. Aber der Anwender der mich darauf ansprach hatte diese Konstellation nicht sondern ein natives Windows auf einem 7. Gen Core-i5 mit iGPU. Mit dedizierten Grakas (egal ob Highend oder Sparbrötchen) treten die Probleme nicht auf. Zumindest konnte ich subjektiv nichts feststellen.

Soeben habe ich noch interessante, aber genauso unerklärliche Zusammenhänge entdeckt: Ist das Formular auf dem der VST liegt maximiert (Windowstate=wsMaximized), sind die "Bremseffekte" ungleich stärker als bei WindowState=wsNormal. Selbst dann, wenn ich das Fenster manuell auf die komplette Größe des Bildschirms ziehe. Zweitens: Auf einem sekundären Bildschirm wird langsamer gezeichnet als auf einem Primärbildschirm. Drittens: Paradoxerweise wird das Geruckel weniger, wenn ich das Form mit dem VST auf DoubleBuffered=True setze.

Meine Vermutung geht da in Richtung einer Konstruktionseigenart (möchte nicht von Fehler sprechen) im VST. Dort werden ja ganze Kaskaden von Paint-Events aufgerufen, teilweise mehrfach (an Stage-Werte gebunden). Normalerweise wird da nur ein Zeiger auf das eine Canvas-Objekt des Treeview und ein Rectangle übergeben. Ich möchte aber nicht ausschließen, dass es irgendwo in den Tiefen des VST auch Bitmap-Kopien gemacht werden.

Wenn nun viele aufeinander folgende Zeichenoperationen auf einem GDI-Canvas erfolgen und die Videohardware ohnehin langsam ist, hat man anscheinend die beschriebenen Probleme.
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden

Geändert von Codehunter (15. Mär 2019 um 13:02 Uhr)
  Mit Zitat antworten Zitat