Gui-Implementierungstechniken

Ich habe mit einigen spielorientierten GUI-Bibliotheken gearbeitet, um eine gute Passform zu finden. Insbesondere eine GUI, die unter Windows, Linux, iPhone und Android mit minimalem Spezialcode funktioniert.

Beim Basteln sind mir einige Bibliotheken aufgefallen, die ihre GUIs gerne in eine Off-Screen-Textur rendern, die stattdessen nur die Textur anzeigt.

Ist dies eine gängige GUI-Technik?
Gibt es nicht einen Leistungseinbruch bei sich schnell ändernden GUIs?

Wäre ich der Implementierer, hätte ich gerade die GUI direkt in jedem Frame gerendert. Gibt es etwas besonders Falsches oder ineffizientes direktes Rendern?

Update: Mit "spielzentrierter GUI" meine ich ein GUI-Framework, das weder das Fenster noch die Hauptschleife besitzt. Es gibt andere Funktionen, die ich hinzufügen möchte, aber die Hauptschleife ist die einzige kritische. Dies umfasst normalerweise verschiedene Rendering-Backends, Eingabeinjektion und eine Aktualisierungsmethode.

Ja, dies ist eine gängige Technik, und zwei unmittelbare Vorteile fallen mir ein:

1) Die Render-to-Texture-Technik, um die inhärenten Probleme zu umgehen, die mit der Unterstützung mehrerer Auflösungen und / oder Seitenverhältnisse verbunden sind. Sie können die Textur auf Ihre Bildschirmgröße skalieren oder einfach in der Mitte rendern. Dies ist nur eine Möglichkeit, Ihr Koordinatensystem zu virtualisieren.

2) Wenn es auf eine Textur gerendert wird, kann dies auf ein Netz oder ein Quad angewendet und transformiert werden. Wenn Sie beispielsweise möchten, dass Ihre GUI (Menü) in einem Winkel von 30 Grad zur Kamera angezeigt wird, rendern Sie zur Textur, wickeln die Textur in ein Quad und transformieren das Quad dann.

Das meiste Rendern in eine Textur ist im Wesentlichen dasselbe wie das Rendern in einen Puffer. Nein, es gibt kaum oder gar keine Leistungseinbußen.