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