PeterX wrote:
But what is immediate mode? I looked it up in the forum and the wiki, but didn't find anything. And I don't understand the two wikipedia articles (IMGUI and immediate mode). I also looked at the following page and still don't understand it:
https://docs.microsoft.com/en-us/window ... diate-modeThis is probably heading off topic, but...
As nexos mentioned, it generally means there is not a lot of retained state. For IMGUI, it borrowed the idea and term from ancient D3D. Around D3D/DX3, the API offered the low level Immediate mode, where you fed it data for raw triangles, every frame, along with any render state changes needed as they came along. This is more or less how OpenGL worked at the time, but D3D did it in a much more painful way. D3D used an Execute Buffer concept, where you fed it what was essentially a carefully constructed bytecode stream with inline data to render. Those buffers, in usual MS style, of course had to be reserved, allocated, locked, filled, unlocked, submitted, and collected. You were expected to either just know the appropriate size, or do a bunch of queries to determine it, and naturally the optimal size would vary depending on the workload, driver, and hardware. OpenGL just had you make a (admittedly large) number of function calls, and dealt with the buffering under the hood. The driver/hardware didn't do any fancy reordering or anything, it did everything in the order presented, and at one point or another, tended to do it more or less immediately while you were feeding it, aside from maybe requiring some sort of Flush call if you wanted to spin on some results.
To make dealing with D3D a bit more humane for mortals, MS also offered a Retained Mode that sat on top. Instead of dealing with raw triangles, you fed it actual meshes, and had them arranged into a persistent scene hierarchy, providing methods to mutate the hierarchy as needed. They would have associated textures and render states, and the API would figure out the ordering and nested transforms on its own. These days that sort of thing would be dealt with more in a framework or engine, but this was 1996, and the only engines that really counted were iD's and BUILD, and neither one did hardware rendering yet. Later on, the sort of stuff Retained Mode covered got resurrected as the XNA framework.
GUI frameworks and APIs traditionally work more like Retained Mode graphics. You create a bunch of widgets, feed them into the hierarchy, and the general updates are handled under the hood. Rendering tends to revolve around dirty rectangle updates, or something similar (like the Win32 Invalidate/Paint cycle), and everything tends towards a very event driven setup.
IMGUI applies something more like the Immediate Mode graphics API style to things. It doesn't keep track of anything from frame to frame, you tell it what things it should display that frame, and track it yourself. It very much derives from the traditional game loop where you're redrawing the entire thing each time anyways. Any and all state needed for rendering is grabbed on the spot, and there's no lifetimes or marshalling needed for things like a status display or such. It's original use case was lightweight, simple GUIs for editors, testbeds, and demos -- things like a model or animation viewer.
Which works better for a particular use case varies. If you are creating something that works very much like the things one of the frameworks provides, it might be better to stick with one of them -- though modern threading and such can make that a real pain, and all of the frameworks involve a significant amount of boilerplate code everyone just copy-pastes from stackoverflow. On the other hand, if you have some custom controls you'd want to provide, or are particular about how you keep the data around, immediate mode may make that a lot easier to deal with. It tends to mean you have to do a bunch of the framework level stuff (layout, input processing, etc) yourself, but generally allows it to be tailored for your specific circumstances.