Comment by pjmlp
4 days ago
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.
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?
https://learn.microsoft.com/en-us/windows/win32/direct2d/com...
I even remember WinG, Win32s and co.
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.