Hi,

ich hab nun schon mehrfach die erfahrung machen muessen das zu kleine VBOs sehr ineffizient sind, und auch haeufige Texturwechsel etc... Ein simples beispiel ist mein UI Framework, bei dem ich mal sehr viele Labels hatte die alle ca. 5 buchstaben hatte und dementsperchend viele VBOs mit jeweils 10 Triangles waren.

Ich frage mich da, gibt es bessere methoden z.B. Text zu zeichnen als mit texturierten Quads in einem VBO?
Natuerlich kann man noch alle labels in einen VBO zusammenfassen etc. aber vieleicht gibt es ja auch was, was ich nicht weiss.

Wie ich darauf komme? Durch die Betriebssysteme... Windows 7 z.B. nutzt ja zur Darstellung komplett Direct3D (?).. oder MacOSX komplett OpenGL. Bei beiden ist es voellig egal wieviele kleine Labels man hat und wieviele verschiedene Schriftarten diesen nutzen etc.

Also die Systeme werden ja z.B. sicher nicht die Schrift in eine Textur packen und darueber zeichnen, oder? Nur, wie dann?
Via Shader halte ich auch fuer unwahrscheinlich da sie es auch schnell konnten bevor es Shader gab..

Erleuchtet mich bitte

Aya~

Ich kann nur von meinen Erfahrungen mit Compiz (Linux) reden. Aber da das auch super auf relativ alter (eeePC) Hardware läuft, gehe ich hier davon aus, dass viel mit dem Immediate Mode bzw. Displaylisten gemacht wird.

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Keine Ahnung wie die das machen, aber hab ich das richtig verstanden, das du für jedes Zeichen eine extra Textur verwendest? Wenn ja dann "Texturatlas".

Was auch noch geht ist das du statt für jedes Label ein extra VBO anzulegen kannste doch auch ein großes VBO nutzen und nur bestimmte Bereiche rendern.
Also statt glDrawElement nutzt du dann glDrawArrays oder noch besser glMultiDrawArrays.

Wieviele Label hast du denn?

Du kannst einen Texturatlas mit allen Zeichen anlegen. Zusätzlich brauchst du eine Lookup-Table (Textur) die dir sagt wo welches Zeichen in der Textur liegt, wie groß es ist, ggf. zusätzliche Daten wie Kerning etc. Eine weitere Textur oder ein Uniform-Array gibt dir dann einfach nur noch den String (z.B. ASCII-Code) mit dem Text.

All diese Daten kannst du dann mit einem Vertexshader lesen und einen Universal-Vertexbuffer mit >100 Zeichen entsprechend transformieren bzw. die Texturkoordinaten richtig setzen.

Es macht ggf. Sinn die 2D-Position jedes Zeichens auf der CPU vor zu berechnen und ebenfalls via Uniform/Textur zu übergeben, da du sonst im Shader für jedes Zeichen alle Zeichen davor verarbeiten musst.

=> Jedenfalls reduzierst du mit diesem Ansatz bei dynamischen Texten die Datenmenge die in jedem Frame zur Grafikkarte übertragen werden muss. Bei statischen Texten ist es ggf. sinnvoller alle Buchstaben in einen großen VBO zu packen.



Hä? Auch mit glDrawElements kann man nur einen Teil des Indexbuffers rendern und/oder der Indexbuffer muss nicht den ganzen Vertexbuffer abdecken. Hier war vermutlich irgendwas anderes gemeint?

_________________
Yeah!

Du verstehst da glaube was falsch.

Momentan scheint Aya das so gelöst zu haben:
Label1 nutzt VBO1
Lavel2 nutzt VBO2
Label3 nutzt VBO3

Sie könnte aber auch
"Label1, Label2 und Label3 nutzen VBO1"
machen.


Soll heißen EIN VBO für jedes Labels (in dem Beispiel 3). Sie könnte aber auch EIN VBO für ALLE Labels nutzen. Dabei sind die Vertexdaten aufeinanderfolgend.
Mit glDrawElements würde sie immer alles zeichnen bis zur angegebenen Vertexanzahl (count), wenn sie jetzt aber nur das dritte teichnen will muss sie das erste und das zweite mit zeichnen. glDrawArrays hat aber einen Start-Parameter der es ihr erlaubt nur das dritte zu zeichnen (als Beispiel). Wenn sie ALLE auf einmal zeichnen will kann sie natürlich auch glDrawElements nutzen.

Ok, ich war bis eben im festen glauben das glDrawElements ebenfalls einen solchen Startparameter hat.
*Alles*zurück*nehm*und*das*Gegenteil*behaupt*

_________________
Yeah!

Unter Linux (mit Compiz und konsorten) ists immer noch so, dass die Anwendungen über irgendeine Lib dann in ihre Fenster-Textur zeichnen (ohne zu wissen, dass es eine ist). Compiz nimmt das dann nur und matscht das zu der schön bunten Ausgabe zusammen, die wir alle kennen (deshalb nennt man die auch Compositing Window Managers, weil sie die Fenster zusammen compositen. Oder so.)

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Win7 benutzt ein FBO equivalent für das Fenster, aktualisiert nur ausschnitte wegen optimierung.

Microsoft hat ein Patent auf das zeichnen von Fonts über die GPU, dabei wird ledeglich bezier curve über ein Shader gemacht und damit braucht man keine Texturen, keine unterschiedlichen Meshes, einfach nur nen VBO mit allen typischen Buchstaben und das equivalent zu DrawRange. Das soll für Windows 8 und den Tablet support sein aber ist natürlich überall praktisch. GTK und damit Gnome hat das im SVN drin aber darf es nicht mit in die offizielle version rein machen, wegen Patentverletzung. Ein Workaround dafür wird wohl in der nächsten OpenGL Release drin sein. In der aktuellen ist ein Path rendering API als NV extension drin und aufgrund der Praktischen Einsatzgebiete wird auch AMD das nach ziehen und dann wird es mit 4.3 ARB werden. So die Hoffnung einiger OpenGL Entwickler im OpenGL.org Forum. Damit kann mann Vektorgrafiken aller Art zeichnen.

Back To Topic
Die Lösung ist die Scissor funktion, Windows, Linux und Co rendern nicht das UI neu, sondern nur die Bereiche, die als Fehlerhaft gekennzeichnet sind. Sowas passiert, wenn ein anderes Fenster drüber Fährt, der Fensterstatus sich ändert, Minimieren, Maximieren, Resize.
Diese Events können mehrere Komponenten zum neu zeichnen zwingen, während die eigenen Events wie MouseOver, Focus,... nur eine einzelne Komponente zum zeichnen auf fordert(je nach UI design könnte es auch zu mehreren werden).
Es macht Sinn, das UI über ein extra FBO dar zu stellen und es mit Scissor nur teilweise zu updaten. Mit dem System bin ich vor einigen Jahren super gefahren. Damit renderst du die UI nicht jedes mal neu, sondern zeichnest nur eine Textur und jede Änderung hat nur Einfluss auf ein Teil der Textur.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

das Problem is einfach das man bei einer UI keine VBOs sondern FBOs nutzt (gentoo sagts einen sogar lol) und diese werden nicht durch eine schleife sondern durch Events neugezeichnet. Jedes Objekt hat dabei ein extra event welches einen Flag im Objekt selbst und im Parent-Objekt setzt:

_________________
Meine Homepage