Grafikperformance von Virtual Treeview

[Codehunter]

Hallo!

Ich verwende den VST per Grid Extensions als Virtual Grid. Dabei ist mir aufgefallen, dass die Darstellungsperformance des aktuellen VST ziemlich schlecht ist. Das tritt unter bestimmten Konstellationen teilweise extrem zu Tage und ist stark von der Hardware abhängig. Weil mich das Thema interessiert hat, habe ich auf verschiedenen Maschinen Tests gemacht. Dabei konnte ich folgenden Zusammenhang feststellen:

Auf halbwegs aktuellen Rechnern mit dedizierter (gesteckter) Graka und nativ 1980x1080 bedient sich so ein Grid (insbesondere beim vertikalen Scrollen) relativ flüssig. Das gilt auch für AMD Ryzen 5 mit integrierter Vega 11. Bei höheren Auflösungen (4K) wird es auf dem Ryzen schon leicht ruckelig. Je schwächer die Graka, umso ruckeliger wird es. Brutal in die Knie geht der VST beim Zeichnen, wenn er auf einem Core i7-7700K auf der iGPU dargestellt wird und das Windows in einer VM läuft. Hier hatte ich nur 128 MB Grafikspeicher konfiguriert. Im Vollbild bei FullHD braucht ein Pagescroll hier fast eine Sekunde um den VST neu zu zeichnen!

Das Problem lässt sich 100%ig auf die "Abteilung Grafik" zurückführen und nicht etwa auf das interne Speichermanagement und CPU-Operationen. Denn dann hätte der Einbau einer dedizierten Graka im Vergleich zur iGPU nicht so einen extremen Unterschied gemacht. Denn alles andere (CPU, RAM, Chipsatz usw.) blieb ja gleich.

Nun stellt sich die Frage: Warum ist das so? Die Interna vom VST ist ja geringfügig unübersichtlich ;-) Weshalb ich da noch nicht in die Tiefe eingestiegen bin. Ich vermute aktuell, dass es mit der Art und Weise zu tun hat, wie die Canvas über die Eventhandler gezeichnet wird. Das Ganze ist ja reines GDI, nicht hardwarebeschleunigt. Jedes OnBefore/After/Irgendwas-Paint-Event erzeugt ja wieder ein TCanvas-Objekt, das wiederum nur den jeweiligen Abschnitt der einzelnen Grid-Zelle enthält (andernfalls könnte man ja mit z.B. negativen Koordinaten über die Zelle hinaus zeichnen). Selbst wenn ich keine eigenen Draw-Events einbaue sondern den VST praktisch "bare Metal" nur mit OnGetText (direkt aus einem Array of String, schneller geht kaum) laufen lasse, sieht es nicht spürbar besser aus.

Nun hat der VST ja gerade wegen seiner Virtualisierung den Nimbus besonders guter CPU-Performance. Ich verwende ihn auch sehr gerne und fasse den originalen TTreeView praktisch gar nicht mehr an. Allerdings bin ich angesichts der Grafikperformance aktuell doch ziemlich enttäuscht. Was nützt es, wenn man 100.000 Nodes in Millisekunden erzeugen kann, wenn sie so lahm auf dem Bildschirm gepinselt werden?

Wie sind da eure Erfahrungen? Meinungen?

Viele Grüße
Cody

[Aviator]

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.

Aber wenn das sogar mit dem reinen GetText Event nicht richtig funktioniert, dann stellt sich mir wirklich die Frage was bei dir schief läuft. :shock:

Ich habe Programme geschrieben, in denen ich sogar die Selektion selbst male und in jeder Column noch ein Icon platziert wird (auch selbst gemalt). Der Tree scrollt nicht anders, als wenn ich einfach nur den RootNodeCount setze und kein Event behandele.

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.

[generic]

Ruckeln entsteht bei uns nur, wenn wir die GetText / on*Paint nicht optimal programmiert haben.
z.B. langsame Berechnungen drin haben.

Der größte VST hat 120 Spalten und lädt ca. 33000 Zeilen.
Da merkt man die Menge, aber nicht so auffällig wie du es beschreibst.

[Codehunter]

Zitat:

Zitat von Aviator (Beitrag 1427810)

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.

Zitat:

Zitat von Aviator (Beitrag 1427810)

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.

[TiGü]

Hast du das Problem schon auf Betriebssystemebene/GDI mit dem "Rohitab API Monitor" untersucht?

[Bünni]

Ich arbeite gerade auch mit der Komponente. Welche Version benutzt du? Ich benutze 6.7 und habe keine Probleme soweit.

[Codehunter]

Zitat:

Zitat von Bünni (Beitrag 1427856)

Ich arbeite gerade auch mit der Komponente. Welche Version benutzt du? Ich benutze 6.7 und habe keine Probleme soweit.

Ich habe die 7.1 vom Dezember letzten Jahres.

Zitat:

Zitat von TiGü (Beitrag 1427855)

Hast du das Problem schon auf Betriebssystemebene/GDI mit dem "Rohitab API Monitor" untersucht?

Interessantes Tool. Muss ich mir nächste Woche mal anschauen.

[mkinzler]

Schon mal mit 7.2 versucht?

[Codehunter]

7.2 schaut genauso aus. Mittlerweile verorte ich das Problem innerhalb der VirtualBox Guest Additions. Die Darstellung ist auch in anderen Programmen teilweise sehr langsam. Wohl auch abhängig davon, ob diese GDI oder DirectDraw verwenden.

[hoika]

Hallo,
nun das lässt sich doch Evaluieren (schönes Wort ;) ),
wenn das Performance unter Windows nativ getestet wird.

Hier noch mal der Link mit den VirtualBox-Einstellungen:
https://www.virtualbox.org/manual/ch04.html

Vielleicht muss da noch was gesetzt werden.

[Codehunter]

Ich konnte das Problem ausfindig machen. Es liegt an der Kombination von Win-10-Gast, Grafikemulation und Paravirtualisierung. Nach vielen Stunden Testen hat sich die Kombination aus VirtualBox 6.0.5 (neuestes Test-Build), VBoxSVGA-Emulation (deshalb auch 6.0.5 weil mein Gast eine EFI-Installation ist und vor 6.0.5 funktioniert VBoxSVGA nicht EFI) sowie der KVM-Paravirtualisierung als funktionierend herausgestellt. Vorher hatte ich VBoxVGA und Hyper-V.

Die GDI-Grafik ist jetzt deutlich flüssiger. Merkt man schon wenn man nur ein Fenster verschiebt. Vorher nur auf dem Host flüssig und in der VM ruckelig, jetzt beides fast identisch.

Halten wir mal fest, dass VirtualTree an dem beschriebenen Problem unschuldig war. Trotzdem hat das Problem schön gezeigt, dass die Art und Weise, wie der VST sich zeichnet, doch recht aufwendig ist. Auf bestimmten, recht schwachen Maschinen kann das zum Problem werden. So auch bei meinem Testanwender, der gar keine VM nutzt sondern eine Intel-iGPU mit einem nativen Windows.

Ferner bleibt die Feststellung, dass Intel zwar (zumindest bis der AMD Ryzen kam) die besten CPUs baut(e), jedoch bei den GPUs kläglichst versagt.

[DieDolly]

Zitat:

Ferner bleibt die Feststellung, dass Intel zwar (zumindest bis der AMD Ryzen kam) die besten CPUs baut(e), jedoch bei den GPUs kläglichst versagt.

So würde ich das nicht zusammenfassen. Wer ordentliche und flüssige Grafik gepaart mit ordentlicher CPU-Power will, der soll sich eine dedizierte Bürografikkarte anschaffen.
Von kläglich versagen kann man hier in keinem Fall reden. Genau so wenig kann man Äpfel mit Birnen vergleichen.

AMD hat, und das auch noch nach über 15 Jahren und länger, die wohl schlechtesten Sockets die es gibt. Von PGA mal ganz abgesehen, obwohl LGA oder BGA der Stand der Dinge ist.
Wenn man dann auch noch eine schlecht konfigurierte VM nutzt, dort die Grafikleistung schlecht ist und dann Intel schlecht macht, finde ich das ein sehr schwaches Argument.

[Codehunter]

Doch doch, ich bleib dabei. Um zu präzisieren: Die OpenGL-Treiber von Intel sind schlecht. Das scheint bei manchen Programmen, wozu VirtualBox zählt, aber auch manche Grafiksoftware wie z.B. PaintShop Pro, gewaltig Probleme zu machen. Dedizierte Grakas sind wohl auch deshalb eine Hilfe, weil es eben keine dedizierten Intel-Grakas gibt. Insofern kann da nicht so viel schief gehen.

Stand heute würde ich jedenfalls niemandem mehr zu Intel-Prozessoren im Office-Segment raten. Die Ryzen-G mit Vega-11 sind da aktuell das Maß der Dinge.

[DieDolly]

Preis-/Leistung = AMD (low budget, PGA = sehr schlecht)
Qualität = Intel (LGA, wenig anfällig)

[Codehunter]

Zitat:

Zitat von DieDolly (Beitrag 1428197)

Preis-/Leistung = AMD (low budget, PGA = sehr schlecht)
Qualität = Intel (LGA, wenig anfällig)

Hehe, ich war seit 1996 auch immer auf Intel unterwegs und genauso davon überzeugt wie du. Dann hab ich den Ryzen 5-2400G ausprobiert. Ergebnis: Die Binsenweisheiten von Anno duttemal treffen nicht mehr zu.

[Codehunter]

So, spätes Update zum Thema:

Ich habe die VM deutlich beschleunigen können und zwar ohne jegliche Änderungen an der Hardware. Nur durch Einstellungen:

• Dynamisch alloziierte virtuelle HDD in eine mit fester Größe konvertiert
• Anzahl zugewiesener CPU-Cores um einen REDUZIERT
• VirtualBox von 5.2.18 auf 6.0.8 geupdatet
• Grafikkarte von VBoxVGA auf VBoxSVGA umgestellt
• Chipsatz von PIIX auf ICH9 umgestellt
• 2D- und 3D-Beschleunigung DEAKTIVIERT
• Netzwerkkartentyp auf Intel Pro 1000 MT Server geändert
• SSD auf der die virtuelle HDD liegt entrümpelt und Partition verkleinert, damit der SSD-Controller genug Spielraum fürs Wearleveling hat
• Einstellung "SSD-Laufwerk" für die virtuelle Platte aktiviert
• Windows Defender im Gastsystem komplett deaktiviert

Insgesamt lässt sich sagen: Weniger ist definitiv mehr. Die Virtualisierung sollte nicht zu viele Resourcen okkupieren, sonst würgt man das Hostsystem ab. VirtualBox setzt keine automatischen/intelligenten Limiter wie z.B. VMWare sondern bleibt stur auf seinen VM-Einstellungen bis dem Host die Puste ausgeht.

Die Kombination VBoxSVGA mit DEaktivierter Beschleunigung führt zu einer rapiden BEschleunigung. Eigentlich widersinnig bis man in den Wikis bei Oracle den Hinweis findet, dass sie die 2D-Beschleunigung auf Intel-CPUs in Software emulieren, auf AMD dagegen in Hardware umsetzen. Auf Intel also sozusagen entschleunigte Beschleunigung :evil:

Jetzt hoffe ich nur, dass das Win10 die manuell eingetragene Hardware-UUID so akzeptiert und nicht aufgrund der ganzen "Hardware"-Änderungen mit einer Neuaktivierung kommt. Ich hasse diesen blöden Sprachcomputer von Microsoft!

Und dann war da noch... doch eine kleine Hardware-Modifikation: Ich beging Genozid an einer recht ausgeprägten Wollmaus-Population :lol:

[Codehunter]

Und noch ein Update:

Ich habe zunächst bei meinem Linux-Host vom Cinnamon-Desktop auf LXDE4 XFCE4 gewechselt, weil Cinnamon gerne mal 3 GB RAM belegt hat. Das hat aber kaum Auswirkungen auf die VM gezeigt. Kam mir sogar etwas langsamer vor. Allerdings nimmt sich LXDE4 XFCE4 nur 300 MB RAM, daher belasse ich das so.

Danach hab ich mir das BIOS vorgenommen und Schritt für Schritt Einstellungen geändert und getestet. Nach und nach ließ sich da ein Muster ableiten: Je mehr Energiesparoptionen ich deaktiviert habe, umso flotter lief die VM. Am meisten gebracht hat eine Option "Dem Prozessor erlauben, auf die Spannungsregler zuzugreifen", welche ich DEaktiviert habe.

Summa summarum laufen die Änderungen im BIOS auf ein typisches Overclocking-Szenario hinaus. Allerdings ohne aufgedrehte Taktraten oder Kernspannungen. Vorallem dynamische Taktveränderungen scheint VBox gar nicht zu mögen. Details zu nennen wäre wohl müßig, weil jedes BIOS anders aussieht und die Optionen anders nennt. Man muss sich wohl rantasten.

Im Moment bin ich sehr zufrieden mit der Performance. Ich könnte mir vorstellen, der Code von VirtualBox ist nicht optimiert auf das teils exzessive dynamische Throttling moderner CPUs.

[Codehunter]

Eine weitere Erkenntnis der letzten Tage möchte ich hier noch ergänzen: Man sollte die VirtualBox-VM nicht mit einer ungeraden Zahl CPU-Cores konfigurieren. Als es zuletzt so warm war ist mir aufgefallen, dass der CPU-Lüfter alle 10 Sekunden plötzlich hoch drehte, ein laufender Radiostream plötzlich Schluckauf bekam und der Mauszeiger bei Bewegungen Hopser machte.

Ein Blick in die CPU-Auslastung und die Thermalsensoren der Hostmaschine zeigte, dass VirtualBox zwar tatsächlich so viele Cores nutzte wie zugeteilt waren (in dem Fall drei). Jedoch lief einer davon zyklisch mit 100% Auslastung und stieß fast an die 80°C-Grenze, während die anderen Cores bei ~ 40°C lagen. Der Effekt tritt reproduzierbar NICHT auf, wenn ich die VM mit zwei oder vier Cores konfiguriere.

Ob das nun eine Eigenart von VirtualBox oder dem Win10-Gast ist kann ich nicht genau sagen. Ich würde auf Windows tippen, weil ich ähnliches nicht beobachten konnte wenn ich eine identisch konfigurierte VM mit Linux-Gast gestartet habe. Möglich dass der Windows-Kernel auf einem Single- oder Triple-Core nicht richtig skaliert. Vielleicht weil es die in freier Wildbahn so gut wie nicht gibt?