Ah, my friend, are you seriously quizzing me on code I wrote 30 years ago and haven't revisited since?
But you ask an honest question, so I will give you an honest answer: I have no clue!
We didn't have any terminology like immediate or retained. 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?
I should explain that our team didn't write all of the "visual" part of VB. We built a product called Ruby (no relation to the programming language) that was originally going to be a user-customizable desktop for Windows 3.0, replacing ProgMan and FileMan. After we turned it over to Microsoft, they decided to combine Ruby with Basic to make a full programming environment, and of course they made many changes and additions along the way.
There are many fun stories I could tell from that era, like the true origin of the term "fire an event", but I'm afraid none of them will involve immediate or retained mode GUIs... :-)
> Graphics APIs can be divided into retained-mode APIs and immediate-mode APIs. Direct2D is an immediate-mode API. Windows Presentation Foundation (WPF) is an example of a retained-mode API.
No, we did not use that documentation. There was no such thing as Win32 at the time, and certainly no Direct2D or WPF. How could we have used Win32 docs? We were just 16-bit Windows programmers, we weren't time travelers!
> 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.
But you ask an honest question, so I will give you an honest answer: I have no clue!
We didn't have any terminology like immediate or retained. 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?
I should explain that our team didn't write all of the "visual" part of VB. We built a product called Ruby (no relation to the programming language) that was originally going to be a user-customizable desktop for Windows 3.0, replacing ProgMan and FileMan. After we turned it over to Microsoft, they decided to combine Ruby with Basic to make a full programming environment, and of course they made many changes and additions along the way.
There are many fun stories I could tell from that era, like the true origin of the term "fire an event", but I'm afraid none of them will involve immediate or retained mode GUIs... :-)
Update after seeing your subsequent edit:
> Even the Win32 API documentation uses the terms https://docs.microsoft.com/en-us/windows/desktop/learnwin32/... Presumably you used that documentation to build VB?
(and from the link)
> Graphics APIs can be divided into retained-mode APIs and immediate-mode APIs. Direct2D is an immediate-mode API. Windows Presentation Foundation (WPF) is an example of a retained-mode API.
No, we did not use that documentation. There was no such thing as Win32 at the time, and certainly no Direct2D or WPF. How could we have used Win32 docs? We were just 16-bit Windows programmers, we weren't time travelers!