GDI, GDI+ oder doch Direct2D?

[KrasserChecker]

Also ich kann dir da GDI+ sehr ans Herz legen. Habe das in einem meiner letzten Projekte erfolgreichen eingesetzt. Dabei ging es um eine hochperformante 2D-Kartendarstellung mit dyn. Overlays mit bis zu >10.000 Elementen.

Geholfen hat mir dabei diese Bibliothek hier, die den Zugriff auf Gdi+ scehr schön vereinfacht und mit OOP kapselt:
http://www.bilsen.com/gdiplus/index.shtml

[Medium]

Man kann es drehen und wenden wie man will: GDI+ ist praktisch abgekündigt. Natürlich kann man damit noch viele Dinge tun, und es ist in vielen Belangen besser/schöner/schneller als die gute alte GDI, und "legacy" Anwendungen würde ich - sofern bereits auf GDI+ basierend - auch eher zögerlich bis garnicht so massiv umschreiben. Aber es bleibt dennoch abgekündigt, und wird spätestens ab Win8 komplett in Software laufen, und war an und für sich auch vorher schon nie für Programme gedacht, die eine gewisse stabile Framerate einhalten mussten.

Wenn man es "richtig" machen will, und die Geschwindigkeit einfach braucht, und auch im nächsten Windows (oder anderen OS) nicht nackt dasteht, bleibt als größter gemeinsamer Nenner, dessen Standard auch schon seit etlichen Jahren nach unten hin recht beständig und brav behandelt wird - und zwar in Hardware wo möglich - ist OpenGL. Wenn man nach dem besten (Kompromiss aus Geschwindigkeit und Kompatibilität) sucht, ist das eine verdammt gute Antwort.

Natürlich ist der Schwung von GDI zu GDI+ gemütlicher. GDI->OpenGL entspricht einem Rewrite des GUI inkl. einem eigenen VCL-Ersatz, und ggf. auch einem ganzen Haufen Lernaufwand (wir reden über Mannwochen wenn man ganz ohne 3D-API Erfahrung da dran geht und es wirklich verstehen will - sprich von der Pike auf, ohne aufgeblasene und plattformeingrenzende Frameworks). Aber wenn die Frage lautet "was ist das beste?", bleibt OpenGL es eine verdammt gute Antwort, die sowohl einen prima Mittelweg für diverse Anforderungen, als auch auf den meisten Endgeräten eine "nah am möglich machbaren" Performance bietet. End of Story.
Wer möglichst einfach migrieren will, muss anders fragen.

PS: FMX nutzt zwar auch OpenGL, ist aber imho noch viel zu unausgereift und "kantig" (codemäßig) um es in ernsten Projekten einzusetzen. Zudem bringt es, diversen Blogs nach, noch zu viel "bloat" und undurchdachten Code mit sich. Wenn es, jetzt für mich persönlich, um ein kommerzielles Produkt ginge, würde ich einen Teufel tun und auf FMX setzen. Wenn sich alles in XE4 oder so mal langsam gestzt hat, dann guck ich da nochmal drauf.

[blackfin]

Hach, wie ich deine Antworten doch immer so mag *schmunzelt*
Nein, das war keine Ironie!

Meiner Meinung liegt die Hemmschwelle bei OpenGL nur an der extrem steilen Lernkurve...hat man es jedoch mal gerafft (wobei es meiner Meinung nach im Leben nicht möglich ist, allles davon zu raffen), findet man Dinge wie GDI+ eher lächerlich.
Ja, OpenGL wirklich zu verstehen ist schwer, aber wenn sich die Lichter gen Stirn neigen, kann man das CPU-Zeug so gut wie vergessen.
Wo man sich bei GDI+ mit Transparenz oder sonstigen Bild-Manipulationen mit der Performance abkämpft, hat man das Zeug mit Shadern in tausendfacher Performance in OpenGL wesentlich leichter geschrieben.....jedoch, leider nur dann, nachdem man zumindest das Red- und Orange-Book auswendig kennt.

[Namenloser]

Schwer zu verstehen finde ich OpenGL nicht, aber die Verwendung ist mitunter sehr mühsam.

Je nachdem, was man machen will, ist OpenGL mehr oder weniger gut geeignet. Wenn man nur ein einziges Fenster (bzw. Render-Buffer) und eine regelmäßige, statische Renderschleife hat (wie z.B. bei vielen Spielen), ist OpenGL gut geeignet. Wenn man hingegen flexibel Grafiken in verschiedene Buffer rendern will, steigt der Anteil des Boilerplate-Codes enorm an.

Dadurch, dass OpenGL nur einen einzigen, globalen Zustand kennt, muss man nämlich immer daran denken, alle Einstellungen, die man setzt, wieder rückgängig zu machen – und das auch noch möglichst effizient. Wenn man, mal übertrieben gesagt, für jedes Dreieck alle Einstellungen setzt und wieder zurücksetzt, war es das bald mit der überlegenen Performance . Die Treiber (zumindest die von NVidia) prüfen leider nicht mal, ob der neu gesetzte Wert sich überhaupt vom alten unterscheidet, sondern führen einfach stumpf die Anweisungen aus. Es liegt also an der Anwendung, den Status zu tracken und redundante Befehle zu vermeiden.

Ein absoluter Performance-Killer ist nach meiner Erfahrung das abwechselnde Rendern in verschiedene Framebuffer-Objects. Leider sind die Treiber nicht intelligent genug, solche Vorgänge ähnlich wie NCQ bei Festplatten zu optimieren, sondern switchen jedes mal hin- und her, was extrem langsam ist. Meine Lösung war am Ende, alle meine Zeichenbefehle zu puffern, indem sie zunächst in einen programminternen Queue geschrieben werden (pro Framebuffer einer), dessen Befehle immer nur in größeren Paketen von z.B. 100 Befehlen tatsächlich ausgeführt werden, um das Context-Switching zu reduzieren. Das führt natürlich selbst wieder zu Overhead, verbesserte die Performance aber buchstäblich um mehrere Größenordnungen.

Generell ist auch ein Problem, dass jeder OpenGL-Treiber sich wieder ein bisschen anders verhält... was bei dem einen Treiber die Performance verbessert, ist bei dem anderen wieder kontraproduktiv usw... da gilt es dann durch viel Experimentieren einen Kompromiss zu finden.

Selbst mit jeder Treiberversion ändert sich das Verhalten wieder. Z.B. gab es von NVidia mal ein paar Treiberversionen, die VSync im OpenGL-Modus über ein Busywait implementiert haben. Ich habe tagelang nach der Ursache gesucht, warum mein Programm auf einmal so eine hohe CPU-Last erzeugt, bis ich gemerkt habe, dass es am Treiber lag...

[christian.noeding]

OK, dann sehe ich für GDI+ und OpenGL schon mal ein paar Pros und Contras. Danke schon einmal für die zahlreichen Infos. Für OpenGL könnte man ja auch unter Umständen Andorra2D verwenden. Man muss das Rad ja nicht komplett neu erfinden. Ich muss aber noch einmal nachhaken: wie sieht es mit TDirect2DCanvas aus, oder ist das noch zu neu, dass es noch keiner verwendet hat? Klingt ja eigentlich laut Beschreibung am vielversprechendsten, da man viele bekannte GDI-Zeichenoperationen weiterverwenden kann.


viele Grüße,
Chris

[Namenloser]

Bei Direct2D sehe ich in erster Linie den Nachteil, dass es erst ab Vista läuft...

[christian.noeding]

Tja,

also zwischen GDI-Canvas mit BitBlt() und Direct2DCanvas kann ich unter Win7 64Bit keinen wirklichen Unterschied feststellen. Wenn ich mit einem Threaded-Timer die Oberfläche bei D2D mit höherer Geschwindigkeit neuzeichne, bleibt zwar die CPU-Belastung nahezu 0% und es wird schnell neugezeichnet, allerdings friert mir das Hauptprogramm ein. Man müsste also die Zeichenroutinen dann in einen Extra-Thread einbauen. Wenn ich einen normalen VCL-Standard-Timer verwende kann ich gar keinen Unterschied zu BitBlt() feststellen.


Im Anhang habe ich ein kleines Demo-Programm, welches beide Varianten verwendet (BitBlt() und D2DCanvas). Ich zähle in der Zeichenroutine einfach eine Word-Variable hoch und skaliere damit mein Rectangle, welches auf der Canvas gezeichnet wird. Bei der GDI-Variante zeichne ich zunächst auf ein TBitmap32 aus der GR32-Sammlung und blitte es dann mit Bitblt auf die Paintbox. Bei der D2DCanvas zeichne ich direkt auf die Canvas. Es ist jetzt wirklich die Frage, ob der Aufwand eines Extra-Zeichen-Threads wert ist, wenn GDI auch unter Win7 noch so gut funktioniert. OpenGL schaue ich mir jetzt als nächstes an.


viele Grüße,
Christian

[Namenloser]

Das so zu messen bringt nichts, weil der Timer selbst der Flaschenhals ist
Wenn dann müsstest du es in einer Schleife testen.

[christian.noeding]

Oh - wie wahr

Ich erweitere meinen bisherigen Code jetzt erst einmal mit Direct2D-Canvas, da das am wenigsten Aufwand macht (bislang ja GDI). Dann läuft das Programm auch noch unter WinXP, da ich dort dann mit GDI zeichne. Sollte das am Ende immer noch nicht zufriedenstellend schnell laufen, wechsle ich auf Andorra2D.


Vielen Dank an Euch Poster.


Viele Grüße,
Christian

[Namenloser]

Ah, ich wusste nicht, dass TDirect2DCanvas das gleiche Interface wie TCanvas hat (habe ich unter TDE nicht). Ja, in dem Fall würde ich das auch nutzen... mehr Performance wird mit Andorra2D vermutlich auch nicht drin sein.