Hi,

ich stelle grade meine library so um das ich sie auch für OpenGL ES, bzw OpenGL 3.0 nutzen kann.. bedeutet, alles was mit dem immediate mode zu tun hat fliegt raus.

Nun hab ich da aber grad ein konzept-problem.

Für meine UI zeichnet ja jedes element ein simples Quad auf den bildschirm, dafür benutzte ich bisher immer glBegin/glEnd.. wie mach ich das jetzt am gescheitesten??

die einfachste lösung wäre, einfach ein VBO für ein Quad erstellen und da die vertices immer hin und her schieben für jedes quad.. also ein globals quad-vbo welches immer wieder gezeichnet wird.. aber macht das sinn? Oder bremst das die anwendung stark aus wegen den vielen zeichen aufrufen?

Wäre das langsamer als der immediate mode? oder nur nicht so schnell wie es sein könnte wenn man 1000 quads in ein vbo packt?


Die alternative wäre das es ein UI-VBO gibt oder so, wo alle UI elemente sich reinpacken und das wird am ende gezeichnet... aber zum einen ist das ein ziemlicher verwaltungs aufwand, zum anderen gibt es auch hier probleme bei texturen etc.

Und was genau macht den VBO langsam..? ist es das häuftige benutzen von den bind-befehlen, oder ist es das glDraw*?
Denn da bei der UI alle quads nacheinander gezeichnet werden, würde es nur einmal gebindet werden und dann halt sehr oft gezeichnet..


Oder hat noch wer eine komplett andere idee?

Aya~

Hmm - wenn ich mir das so ansehe: Die Lösung für Deine Probleme wäre einfach eine Testanwendung. Ein simples Programm, dass die Zeitdauer der verschiedenen Zeichenvorgänge vergleicht. Du hast doch schon mal Messungen vorgenommen. Einfach ein kleines Testprogramm schreiben und nachmessen. Dann musst Du Dir keine Gschichterln reindrücken lassen, was angeblich schneller ist - dann weißt Du es. Flash hatte so etwas mal angeregt und das wäre sicher sinnvoll wenn wir ein DGL-Benchmarking-Programm hätten, das jeder benutzen kann, denn vermutlich bringt nicht jede Hardware die gleichen Ergebnisse. Testanwendung laufen lassen + Ergebnisse im Forum berichten sollte nicht länger dauern als drei Minuten, und wir müssten nicht immer herumraten.


@Komplett andere Idee: Es gibt da eine Methode, die nur auf Texturen basiert, k.A. wie die funktioniert.

Ja Traude hat Recht: mit einem kleinen Testprogramm dürftest du da wesentlich schneller und präziser ans Ziel kommen. Vergiss aber nicht uns dann hier Bericht zu erstatten Vor dem Problem mit den VBOs in der GUI stehst glaub ich nicht nur du alleine...

Grüße,
~ Philipp

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Ja, ich auch.

Der DGL Benchmark wäre wirklich die beste Lösung.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Also der Aufruf wird garantiert der zeitintensivste Schritt sein; wie viele Quads du in der Zeit
Zeichnen kannst, die ein Aufruf* schluckt, hängt natürlich von der Grafikkarte ab - aber ich denke
mal 1000 sind locker drin ^_^

Auf der anderen Seite wird das UI ja auch relativ oft verändert - demnach wird sich eine Vertexliste
im Hauptspeicher gar nicht vermeiden lassen. Wird im Ende so eine Art Vertex-Array mit dem Sticker
"VBO"

Aber schneller als immediate wird es allemal (nicht, dass es bei einer UI eine Rolle spielen würde).

Edit:
* Nicht zu vergessen die ganzen Matrix-Operationen, damit dein Einheitsquad da erscheint, wo es
soll! Die Texturmatrix/Bindung wirst du sowiso für jedes Element anpassen müssen. Möglicherweise
wäre es sinnvoll, die UI-Elemente im VBO nach Textur zu sortieren.

Da bist Du im Irrtum. Ich habe eine ziemlich ausgefeilte GUI, die mit Displaylisten arbeitet: eine Displayliste pro Form. Einmal erstellen und dann an die Grafikkarte schicken genügt. Eins für ein Viereck, eins für einen Kreis, eins für ein Roundrect, und so weiter.

Übrigens: dieses Benchmark-Programm bräuchten wir in mehreren Geschmacksrichtungen: Pascal, C++, Java, ..... Ich würde die Pascal-Variante machen, zu verwenden mit Delphi und Lazarus, für Linux und Windows. Mac OSX kann ich leider nicht.
Traude

Ich denke zum Thema "Wie optimiere ich das Zeichnen meiner GUI?" sollten wir einen extra Thread aufmachen.

Mich würde das nämlich auch interessieren.
(Meine GUI ist bisher noch gar nicht dahingehend optimiert. Ich habe für jede sichtbare Komponente eine Zeichenfunktion, welche vom Nutzer meiner GUI ausgetauscht werden kann. Bei mir ist also nicht vorgeschrieben, wie gezeichnet wird. Ich gebe nur eine StdDrawFunc() an.)

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Nun, dann mach doch einen Thread auf. Am Beispiel Aya sieht man ganz gut, dass es auch bei einer GUI nicht egal ist, wie schnell sie ist: Aya braucht das für sein Flipbook, glaube ich, wenn man hier zu langsam ist, dann ruckelts.