I think this is the source of the confusion:

> 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?

▲

SigmundA 42 minutes ago | parent [-]

Is Win16 / Win32 GDI which goes back to 1985 an immediate mode GUI?

Win32 GUI common controls are a pretty thin layer over GDI and you can always take over WM_PAINT and do whatever you like.

If you make your own control you musts handle WM_PAINT which seems pretty immediate to me.

https://learn.microsoft.com/en-us/windows/win32/learnwin32/y...

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.

	▲	pjmlp 7 minutes ago \| parent [-]
		No, that is event based programming, and also the basis of retained rendering, because you already have the controls that you compose, or subclass. Handling WM_PAINT is no different from something like OnPaint() on a base class. This was actually one of mindset shifts when moving from MS-DOS into Windows graphics programming.