der Client alle Steuerelemente (visueller Baum/logischer Baum von Steuerelementen) selbst verwaltet und die Grafikobjekte zusammensetzt, um die Steuerelemente der kompletten GUI zu rendern, oder
ohne Nutzung – alsounmittelbar- umfangreicher Umleitungen auf gespeicherte Ressourcen und wo
die Ereignisverarbeitung direkt durch den Client gesteuert und vollständig von ihm implementiert wird (im Gegensatz zu einer gebrauchsfertigen Basis-Ereignisverarbeitung durch ein GUI-System/eine GUI-Bibliothek unter Verwendung vordefinierter Ereignisse/Rückruffunktionen oder Signale/Slots) und
die Listen der zu rendernden grafischen Objekte vom Client verwaltet werden und alle Zeichenbefehle, die zur Beschreibung der gesamten GUI benötigt werden, jedes Mal, wenn ein neues Bild benötigt wird, erneut an die Grafikpipeline übergeben werden müssen.
Schematische Erläuterung des Modus mit gespeicherten Ressourcen eines Grafik-API im Unterschied
Dies impliziert, dass der Client-Code in einem Immediate Mode GUI seine eigenen grafischen Primitive verwaltet und dieses API-Design auch die Implementierung der Grafikpipeline beeinflusst.
Es gibt ein weiteres bedeutendes Entwurfsmuster der Programmierschnittstelle in Grafikbibliotheken – den Retained Mode. Im Retained Mode werden die grafischen Primitive durch das GUI-System/die GUI-Bibliothek verwaltet, oft vor dem Client-Code versteckt.
ein GUI synchron mit der Spielszene oder einer komplexen Grafik aktualisiert werden muss,
ein GUI auf eine Spielszene oder eine komplexe Grafik überlagert werden muss (was in beiden Fällen besonders einfach ist, wenn sowohl das GUI als auch die Spielszene durch die Spielschleife gesteuert werden), oder
ein GUI ein ungewöhnliches Aussehen haben oder mit komplexer Grafik aufgepeppt sein soll.
Typisch für ein GUI-Toolkit für den Immediate Mode ist, dass es
direkter in dem Sinne ist, dass der Baum von Steuerelementen (Widgets) oft ein Baum aus Funktionsaufrufen ist, der wunderbar zusammensetzbar und flexibel ist – aber mit dem schwer zu interagieren ist,
weniger komplex strukturiert und leichter zu verstehen ist (im Sinne von weniger impliziten Annahmen pro GUI-Toolkit-API-Aufruf) – dies führt in der Regel aber auch zu weniger Funktionalität,
für mehr als einen einfachen Baum von Steuerelementen einschließlich Layout (absolute und/oder relative Positionierung in Bezug auf Eltern oder Geschwister) aufwendiger (benötigt typischerweise mehr GUI-Toolkit-API-Aufrufe) zu erstellen und zu verwalten ist,
eine weniger ausgefeilte Entfernung verdeckter Objekte (Z-Buffering), Trefferprüfung, Behandlung von Zustandsänderungen, Bildlauffunktion und Animation für den Fokus/das aktives Steuerelement hat – dies impliziert auch die Notwendigkeit, selbst einen logischen Baum/visuellen Baum von Steuerelementen zu verwalten,
die Vertexpuffer für jedes neue Bild komplett von Grund auf neu aufbauen muss, und folglich
eine ständige Arbeitsbelastung für den Prozessor (CPU) erzeugt.
Deshalb sind Immediate-Mode-GUI-Toolkits eine gute Wahl für alle, die ein einfaches, aber leicht veränderbares und erweiterbares GUI-Toolkit wünschen. Sie sind in der Regel generisch, quelloffen und plattformübergreifend. Eine Möglichkeit, die Flexibilität und Kombinierbarkeit eines Immediate Mode GUI ohne die Nachteile der Verwaltung des Steuerelement-Baumes nur in Funktionsaufrufen mit dem Mangel an direkter Kontrolle, wie die grafische Benutzeroberfläche in der Render Engine gezeichnet wird, zu haben, wäre die Verwendung eines virtuellen Steuerelement-Baumes – so wie React einen virtuellen DOM verwendet.
Implementierungen
Das ursprüngliche Immediate Mode GUI Toolkit ist imgui by Adrien Herubel, das auf OpenGL basiert. Die Idee wurde von Casey Muratori verbreitet. Es existieren weitere Toolkits wie
