> To describe it, I coined the term “Single-path Immediate Mode Graphical User Interface,” borrowing the “immediate mode” term from graphics programming to illustrate the difference in API design from traditional GUI toolkits.
Obviously it’s ludicrous to attribute “immediate mode” to him. As you say, it’s literally decades older than that. But it seems like he used immediate mode to build a GUI library and now everybody seems to think he invented immediate mode?
Difference between game engine and say GDI is just the window buffer invalidation, WM_PAINT is not called for every frame, only when windows thinks the windows rectangle has changed and needs to be redrawn independently of screen refresh rate.
I guess I think of retained vs immediate in the graphic library / driver because that allows for the GPU to take over more and store the objects in VRAM and redraw them. At the GUI level thats just user space abstractions over the rendering engine, but the line is blurry.
Event based or loop based is separate from retained or immediate.
The canvas api in the browser is immediate mode driven by events such as requestAnimationFrame
If you do not draw in WM_PAINT it will not redraw any state on its own within your control.
GDI is most certainly an immediate mode API and if you have been around long enough for DOS you would remember how to use WM_PAINT to write a game loop renderer before Direct2D in windows. Remember BitBlt for off screen rendering with GDI in WM_PAINT?
You are forgeting most folks did not use bare bones C with WM_PAINT and nothing else.
Most sane devs were quick to adopt C++, even Petzold books moved into C++ still during Windows 3.1 days, although the code samples stayed pretty much the C subset common to both languages, see the preface on his book.
As such many games had their own retained frameworks built on top of Win32 controls, wrapped into C++ classes, or if they were casual games, they would build upon OWL, VCL (Borland TP, C++, Delphi), MFC (VC++), VB.
The kind of games where you would get a bootload of shovelware CDs when buying a Media PC with MS-DOS/Windows 3.1.
I wasn't talking about MFC or VB or any higher level abstraction, I specifically was talking about the base Win16/32 GDI gui system that windows started with.
You can take an immediate mode api and abstract it with a retained mode api. My question was is Win32 / GDI immediate.
There was plenty of pure C windows programs and C++ ones that just used Win32.
ImgGui actually uses a retained mode graphics interface so it only sends changes to the GPU while making it look "immediate" thing is its creating internal state and tracking it so its not smash and replace at the driver level.
Win32 / GDI is mostly smash and replace in WM_PAINT, common controls library will abstract it, but looks a lot like ImgGui in that is uses window handles as ID's for internal state while ImgGui has its ID stack which is just a primitive object state system.
The more I look at ImgGui the less immediate it seems, its just a function based api to a retained mode graphic system that tries to hide the state tracking from you by not always exposing the object handle, mostly.
> To describe it, I coined the term “Single-path Immediate Mode Graphical User Interface,” borrowing the “immediate mode” term from graphics programming to illustrate the difference in API design from traditional GUI toolkits.
— https://caseymuratori.com/blog_0001
Obviously it’s ludicrous to attribute “immediate mode” to him. As you say, it’s literally decades older than that. But it seems like he used immediate mode to build a GUI library and now everybody seems to think he invented immediate mode?