Any decent immediate mode framework, including Dear ImGUI, has backends which just send quads to the GPU. The code is imperative but it just winds up filling a vertex buffer.
Re:Immediate Mode GUI Programming
by oasisaimlessly on Monday January 15, 2024 @08:25PM
(#39008276)
Despite both having "immediate mode" in the name, immediate mode OpenGL and immediate mode GUIs share very little in common. Pros/cons definitely don't carry over at all.
Apart from most of your comment being irrelevant for immediate mode UIs, the rest is also at best misleading, since in modern 3D-APIs draw commands are also issued from scratch each frame (if only to kick off GPU shader code).
The very early D3D versions actually had an optional 'retained mode API' in the mid-90's, but that quickly went the way of the Dodo.
You'd have code that would "draw thing 1", move, then "draw thing 2".
Modern pipelines instead have you upload your vertex data to the GPU and write shader code that tells the system how to draw it. They become managed by the GPU and your code cares less about explicit drawing.
Another way to look at this is that "immediate mode" feels much more imperative than the modern asynchronous graphics pipeline. You tell the system to draw or render something, and it immediately does so.
This post has another good explanation with simple code:
https://stackoverflow.com/questions/6733934/what-does-immedi...
It's much easier to wrap your head around immediate mode though, and several tools with this imperative/immediate philosophy (such as imgui) are popular.
Edit:
Here's a fantastic comparison: https://cognitivewaves.wordpress.com/opengl-vbo-shader-vao/
(See "Immediate" vs the more modern code that follows.)