> What we did have was the early Windows API with update regions and WM_PAINT. There was no desktop compositing, so if a window was partially or fully covered and then uncovered, the newly-uncovered area would be invalidated and the window proc would receive a WM_PAINT message to notify it to repaint that area. Could that be related to what you're referring to?
Ye that's it.
So if you drew a shape onto a normal window, it went into the screen buffer, and would be erased if another window covered that part of the screen. If you wanted the shape to be visible again, you had to draw it again when the WM_PAINT message came. VB didn't remember that you used a drawing command and didn't keep the original details of the shape stored anywhere. That's immediate.
If you used one of the VB drawing controls to draw the same shape, then when the window was revealed after being covered, the shape control, an object in memory, was still there in order for the shape to be automatically redrawn by the VB runtime on the WM_PAINT message itself.
A half-way was to make the shape drawing commands write to a separate GDI (the Win32 graphics API) surface, which was then in a sort of retained mode itself, redrawn to the screen whenever the window was revealed. That was the double-buffer option on forms.
> There was no such thing as Win32 at the time
Well you know what I mean. GDI was part of the 16 bit API as well, possibly called WinG back then I think? Obviously they've updated the documentation as they've gone. But Windows included both retained and immediate components back then.
This is awesome, thank you for the conversation. So I guess we were doing immediate mode GUI and just didn't know what it would eventually be called?
We didn't use WinG [1] - it came along years later, and I think only on Win32, not Win16? We did use GDI, of course, it was there from the very beginning, but there wasn't anything resembling retained mode back then. Just WM_PAINT and update regions.
We actually didn't even worry much about having controls automatically redraw themselves. For the most part, we were just wrapping standard Windows controls or combinations of them, and we let those controls respond to their own WM_PAINT messages as usual.
Of course MS undoubtedly made many improvements after we finished our part of the project. Fun times.
> So I guess we were doing immediate mode GUI and just didn't know what it would eventually be called?
On second thought, that's not right either. Immediate mode is like Unity's OnGUI where you draw everything on every frame.
On Win16, you only got a WM_PAINT when needed, and it came with an update region of whatever had been invalidated since your last WM_PAINT. Many apps would optimize by just repainting the update region.
The Mac worked the same way. What would we call this way of doing things, "paint mode"? We never thought of it as a "mode" at the time because there wasn't any other mode.
For me this concept of expose/damage/paint event which bubbles through the window hierarchy is what defines the retained mode.
In theory in immediate mode widget library you can have global state that defines which part of screen has to be repainted if any, but there is not that much of performance benefit because you still end up doing most of the processing for each frame and when there is any damaged region you still in effect redraw everything and clip it to the region.
Ye that's it.
So if you drew a shape onto a normal window, it went into the screen buffer, and would be erased if another window covered that part of the screen. If you wanted the shape to be visible again, you had to draw it again when the WM_PAINT message came. VB didn't remember that you used a drawing command and didn't keep the original details of the shape stored anywhere. That's immediate.
If you used one of the VB drawing controls to draw the same shape, then when the window was revealed after being covered, the shape control, an object in memory, was still there in order for the shape to be automatically redrawn by the VB runtime on the WM_PAINT message itself.
A half-way was to make the shape drawing commands write to a separate GDI (the Win32 graphics API) surface, which was then in a sort of retained mode itself, redrawn to the screen whenever the window was revealed. That was the double-buffer option on forms.
> There was no such thing as Win32 at the time
Well you know what I mean. GDI was part of the 16 bit API as well, possibly called WinG back then I think? Obviously they've updated the documentation as they've gone. But Windows included both retained and immediate components back then.