Note to authors: please define your terms when you first use them, or provide links to the definitions.
Of course I know what a GUI is. I've been building them for decades, and building tools that other developers have used to build GUIs. (I was one of the authors of the "visual" part of Visual Basic.)
But I have never before seen the terms "immediate mode GUI" or "retained mode GUI". And I'm pretty sure there are many developers like me who will have no idea what you're talking about. It takes only a moment to add a quick definition or a link the first time you mention a specialized term, and your readers will definitely appreciate it. Thanks!
(Edited to remove fluff and make the essential point more clear.)
Do you know who his intended audience is? Just because his article got posted here doesn't mean he was writing it for the general HN audience.
Most likely he's writing it for an audience that knows very well the difference between immediate/retained modes. I mean, he's writing it on a blog that's all about graphics programming, game engines, etc. So it would be a bad move for him to define terms common to that field in every article.
I remember an article on the woodworking technique of riving that made it to HN front page, the comments took the author to task for implying riving was invented by Vikings because the article was written for Viking enthusiasts on a Viking enthusiast website.
I don't know, he actually spends half the article explaining the difference between the two. It's just not clear he's going to do that until you get that far. So I think it's strange to suggest that his audience already knows the difference.
>But I have never before seen the terms "immediate mode GUI" or "retained mode GUI". And I'm pretty sure there are many developers like me who will have no idea what you're talking about.
Well, developers who write their own GUI toolkits (what the article is about), probably know retained vs immediate mode. Those are two very basic distinctions when it comes to GUIs.
Retained mode is the average GUI toolkit you probably know (Swing, GTK, Cocoa, etc). Immediate mode is where the GUI is draw directly frame by frame by the application.
In retained mode you deal with buttons, windows, panels, checkbox objects, textboxes, etc, arranged in a tree-like structure.
In immediate mode you deal with painting commands (of course you usually will abstract them to a higher level too). You want a button? You draw a square and the label in it, and depending on the user input (e.g. clicking at the moment or not), you might draw it depressed.
> Retained mode is the average GUI toolkit you probably know (Swing, GTK, Cocoa, etc)
Not quite. Certainly Cocoa, and probably the others as well, are mixed mode.
An NSView has a drawRect:: method that draws that particular view in "immediate mode", with drawing commands of the underlying procedural graphics API (essentially Quartz/CoreGraphics).
If you want pure immediate mode, you create a single NSView and just draw everything.
If you want pure retained mode, you exclusively use predefined widgets, which hide the "immediate mode" drawing that they do.
>An NSView has a drawRect:: method that draws that particular view in "immediate mode", with drawing commands of the underlying procedural graphics API (essentially Quartz/CoreGraphics).
Yes, but that's the case for almost all retained mode GUI toolkits (they provide something akin to that), and it's used as a last resort (when you need a custom look or to implement your own widget, or complicated UI for something like plotting or a piano keyboard, etc).
Regular use of the APIs in Cocoa (and what all books advice) is retained mode style, using pre-made widgets with the Interface Builder and so on. Not "drawRect".
Usage appears to have shifted that way. However, that wasn't the case not so long ago and the fact that a facility is no longer being used (as much) does not mean it's not there. If you need it, it's right there to use as you wish.
Just because you tend not to open the roof doesn't mean your convertible is no longer a convertible, as long as you still can open the roof.
And yes, I did mention that other toolkits probably work the same way.
>Usage appears to have shifted that way. However, that wasn't the case not so long ago and the fact that a facility is no longer being used (as much) does not mean it's not there. If you need it, it's right there to use as you wish.
I recall having discussed this with you here again.
I'd say it was the case for as long as I'm on IT (so, as long as mid-nineties or so). Heck, even back to Delphi and co.
>Just because you tend not to open the roof doesn't mean your convertible is no longer a convertible, as long as you still can open the roof.
Well, if 99% of the car has been designed for one use (A), but has the option (that few use) to do B, doesn't mean the car's a B.
So, this is more like "just because the car has a lot of storage space in the trunk, doesn't mean it's a truck".
> case for as long as I'm on IT (so, as long as mid-nineties or so)
Late 80s for me. What you saw depends very much on which part of "IT" you were in.
When doing forms automation, maybe you only ever saw the widgets. And that's OK. However, forms/widgets are not all of IT and all of UI work. So when doing graphics, DTP, CAD/CAM, document processing etc.: not so much.
>if 99% of the car has been designed for one use
But it hasn't. Not 99% and not one use. These frameworks are flexible and were explicitly designed to be flexible. drawRect:: and handling mouse events is a fundamental feature of the view, and widely used. The fact that you have convenience widget libraries that encapsulate its use (they ALL use it), doesn't mean it's not there.
Just because you use your truck like a car doesn't mean it's not still a truck.
>So when doing graphics, DTP, CAD/CAM, document processing etc.: not so much.
Yeah, haven't done graphics, DTP, CAD/CAM, etc, and I guess immediate mode or mixed mode is more prevalent there.
But I'd say the vast majority of GUIs (whether enterprise or desktop/business apps etc) are forms and regular widgets based. If they need some custom part (e.g. a plot or a custom drawn control) they implement it by drawing it, but still use it in retained mode, in the classic widget tree, embedded in some window, layout widget, etc.
Immediate mode is almost non-existent in enterprise GUI work for example -- except niches like CAD apps for factories or some special case (a custom widget drawn but embedded in an otherwise retained mode UI).
>These frameworks are flexible and were explicitly designed to be flexible.
Yes, they have escape hatches to draw your own widgets when needed.
But their main idea wasn't "immediate mode", but "we provide these ready-made widgets", and they're judged by how many and good those are, not by the ability to drop in drawRect or such.
In the same way, that OpenGL and DirectX is 99% immediate mode, regular GUI toolkits is 99% retained mode (on the API level programmers are meant to use, and mainly use).
Almost any book on GUI programming on Cocoa, GTK, QT, etc I've read, primarily focuses on the available widgets and retained mode use, and any "drawRect" equivalent is an aside about what you can achieve if needed.
No, as I've written, their main idea was to provide mixed mode. On top of which you can provide a widget set. Something like GKS or Phigs was true retained mode graphics, and toolkits like AppKit were reactions to the limitations of those types of mechanisms.
There is a reason the Mac had QuickDraw and NeXT had DPS and not GKS or Phigs. Well, many reasons, but one was that the limitations of pure retained mode graphics systems were well known.
> they have escape hatches to draw your own widgets when needed.
Yes and no. While you can view them as escape hatches if you're primarily doing widget-only programming, they aren't really escape hatches as the entire system is based on / built on them. Just like in Objective-C, objc_msgSend() is not the escape hatch, it is both the basis for all messaging and it enables the escape hatch, which is -forwardInvocation:. Similarly -drawRect:: and responder handling: they are the basis on which everything else is built. Since they are exposed, that means you can build your own views/widgets as peers to the ones provided.
> Almost any book on GUI programming on Cocoa ...primarily focuses on the available widgets
The books I learned AppKit with focused on creating a custom view, drawing with DPS and pswrap, handling mouse events and the responder chain.
What's more - things like drawRect, QPainter etc. are hardly comparable to what a real immediate mode GUI toolkit offers - you'd need to basically reimplement something like Dear ImGUI on top of Cocoa or Qt in order to get something similar.
I didn’t know also, but typing immediate mode.. basically autofills and shows the resulting definition on an iPhone without evening pressing enter. At this point I’m not sure which is more tiring, the lack of an intro/definition, or the expected top comment about the omission. I think, as professionals we can be less hard on each other, especially since we are all too aware of the difficulty in taking time out to write a blog/article.
That's a fair comment, and you are definitely right about the difficulty of finding time to write a blog post!
Please understand that I was not intending to be hard on the author or criticize them. I am offering some writing advice that I hope could be useful for anyone writing technical articles like this. Of course that may just be arrogance on my part. ;-)
What a rude comment. It's not a specialized term. It's a common term. Immediate mode GUI as a concept is well known. Tens of thousands of programmers use Immediate Mode GUIs. There are several well known Immediate Mode GUI libraries used by tens of thousands of projects.
When I don't know a term I google it. I don't assume the entire world revolves around me and that it's the author job to make their article more verbose because everyone reading it might not know every term.
Here's are galleries of some from one of the more popular libraries
I don't think it's rude at all. I did Google "immediate mode GUI" after reading the first paragraph, because I also didn't know what it meant. The first three results were a Wikipedia snippet which didn't help my understanding at all, a Gist that begins with "Before you continue, if you don't know what IMGUI is don't bother reading this", and then third result was this HN comments section.
I would argue that "immediate mode GUI" is an extremely specialised term.
Specialised enough that I didn't come across it during my years of work on Qt. Work that included reading all the manuals, style guides and UI books we could get hold of.
> Specialised enough that I didn't come across it during my years of work on Qt.
Of course you didn't, Qt is retained.
It's a bit like imperative programming vs functional programming. Before functional programming gained any significant traction, imperative programming was just "programming".
Actually immediate mode came first, retained came later for perf reasons (redrawing the entire screen from scratch every frame is slow, even though immediate mode is easier). The original context was however graphics (OpenGL retained vs immediate modes) rather than UI (widget toolkits started out as retained, like OGL retained scene graphs, likewise canvases have always been immediate).
Of course I didn't? I filled a wall with the books I bought and didn't come across the term. What did I do wrong, what books could I have bought but didn't?
How many of those books weren't about the mainstream GUI toolkits (Qt, GTK, MFC, Cocoa, Swing…)? Has even one of those books described something that resemble "let's redraw everything every frame"? If so, how that technique was called?
> what books could I have bought but didn't?
Possibly none at all. Immediate mode anything is mostly a game dev thing, and what happens in game dev tends to stay in game dev. They don't seem to document their practices as much as other fields do.
Hence my suspicion that the authors of your books didn't even know about IMGUI. They just knew about "the" way to do GUI, which happens to involved retained state.
You're letting the tail wag the dog. You're assuming that people know terms that are used in "possibly none [no books] at all", or put differently, that the set of terms used in books for software developers is uncorrelated with the set of terms software developers may be assumed to know.
BTW, the code in Qt that draws rotated/sheared text/pixmaps was influenced in part by a book or chapter by Michael Abrash, as well as by articles in either Graphics Gems or conference papers (memory's fallible I'm afraid).
I did not find it rude and I agree that a short explanation would have been nice. I had heard the terms Immediate Mode GUI and Retained Mode GUI before but I couldn't remember the details. A short reminder would have been nice. Just a sentence.
p.s. I did get a chuckle from your deleted comment that suggested I was living in a cave. After the heat wave we've had here the last couple of days, I wish I were living in a nice cool cave! ;-)
I knew the term and I didn't find the comment particularly rude, even if I don't agree with it fully.
I agree that the docs could have been improved by providing some sort of definition. But I think something as simple as a link to wikipedia could have been enough.
I also agree that the intended target audience will most likely already be aware of immediate vs retained. Adding the aforementioned link would not have hurt said audience anyway.
He wasn't rude, he politely asked people writing articles to try to be more descriptive. However, in my decades in the industry, I've never heard of "Immediate mode GUI" or "retained mode". Not once in 30+ years. I can't be that common.
Agreed. Better to bore people with brief review than alienate a wider audience. I've had people say to me "I know that" angrily when I'm mid-explanation of a concept, but it's better to be thorough. This habit comes in handy in forums or in a room with more than two people. In both scenarios, lurkers/eavesdroppers then get background info and don't walk away misinformed.
It's where it first came to prominence. The earliest D3D api was immediate mode (meaning, bare metal, talking directly via an api to the hardware). Retained mode is about retaining statefulness and some better abstractions to the underlying needs of the hardware (eg automatic texture resampling, etc).
Considering it's an NVidia guy talking: he's been around for a while.
A minor detail, but the very first version of Direct3D was a retained mode API.
In 1995 Microsoft acquired a company called RenderMorphics and turned their Reality Lab [1] API into "Direct3D". The first two versions to ship from Microsoft had both retained and immediate mode APIs, but they dropped the RenderMorphics-based API due to lack of adoption.
Interesting, thanks! That would explain why I and probably many other readers, who have built plenty of GUIs but have not worked specifically with APIs like DirectX, would not be familiar with the term.
The terms are in common use since the 80s at least (no, Microsoft did not invent these terms with D3D). You can prove this in google scholar.
In fact for 3D rendering, retained mode was touted as a the new way forward, there was even a standard predating OpenGL called PHIGS, a retained mode system.. OpenGL was the worse is better (also PHIGS had many limitations basically limiting its use to CAD) backlash promoting its immediate mode in the early 90s.
Retained Mode Direct3D is the first and only place I've really heard that term used. After D3D stopped offering Retained Mode I haven't heard anyone use it except for a couple of articles about "immediate mode GUIs". Last time I saw one of those I had to look it up.
Yes, of course that is true. It doesn't change the fact that it is considered a common courtesy, and a sign of quality writing, to define any unusual terms like this when you first mention them.
It's the same principle as writing readable, self explanatory code. You write your article once, but you hope that many thousands of of people, with all different levels of experience, will read it. If you can take a few minutes to save thousands of readers a minute or two each, that is a big win.
If you really want to do it right, you can link to those Wikipedia articles when you introduce the terms. After all, your reader may be on a mobile device on the bus, where it is easier to tap a link than to copy and paste or retype the term to find out what it means.
I agree that it's important for people to be independent about locating and ingesting information. I also think that it's good to include a quick definition, particularly for stuff that's really specific (indeed - while looking for a definition I found a blog post that starts with "If you don't already know what Immediate Mode GUIs are then please stop now").
I did a Google search but there weren't any clear definitions on the first page or so.
I did search for the Wikipedia article and here's what I got:
"Immediate Mode GUI is a GUI where the event processing is directly controlled by the user. The key is the aspect of retained (RMGUI) vs non-retained UI (IMGUI). In the latter, the user code is holding on its own natural data, in the former it is stored in the GUI system, often hidden from the user code. The immediate mode GUI widget toolkits are more direct and thus less complex, thus they are a good choice for those who want a simple but easily changeable and extendable GUI toolkit, they are usually generic, open source and cross-platform. The original Immediate Mode GUI toolkit was imgui[1] which is based on OpenGL. The idea was popularized by Casey Muratori. There are others such as nuklear[2] with backends for several graphics libraries, kiss_sdl[3] for SDL (Simple DirectMedia Layer) or dear imgui[4] written in C++ (here the jvm port[5])."
First, the quality of this writing isn't great, to the point where it makes it harder to read.
I think that the above definition makes sense if you already know what Immediate Mode is, but it was pretty opaque on my first read (partly because I misunderstood "user" in the first sentence to mean "the customer sitting in front of the computer and using your IMGUI program", instead of "other code that uses the IMGUI").
The definition now makes sense to me after reading other posts here explaining that this was a Direct3D thing.
So yeah - I can see the arguments that we're not the target audience (and I understand that the person who posted this to HN probably isn't the author), but I think that Stratoscope's point that articles posted to the general HN audience would benefit from short, clear definitions (or links to definitions) in the articles is spot-on.
Also, props to Stratoscope for their calm, constructive replies in the face of a lot of disagreement! If we all did this (and I include myself here for sure) the Internet would be a better place.
immediate mode and retained mode are technical jargons sure, but this article is written with a technical audience in mind. It's not like the author has invented the term, nor are the terms used here esoteric at all. Defining it just adds noise tbh.
If an author thinks that defining something inline will add clutter, the simple solution is to link the term to an article that defines it.
We may be a technical audience here on HN, but I wager that the vast majority of HN readers have never heard these terms before, just as I never had.
Based on what kyberias said in a sibling comment, it sounds like these terms will be familiar to those who have written DirectX and perhaps other GPU code, but for the rest of us they are esoteric terms.
It is so easy to add a link when you first mention a term like this. Why not do that?
The article goes on to explain the difference between immediate mode and retained mode in detail after the first example. A link would just distract the reader (the reader would then leave the site to learn about the terms, then come back, only to have them explained again).
Why are you assuming that HN is the intended audience? Just because some random person posted the article here does not mean you are the intended audience of the author. It seems quite presumptious to criticise on that basis.
At the risk of repeating what I mentioned in one or two other comments, I am not criticizing the author, and I am not assuming that HN is the intended audience. (And please don't put words in my mouth like that.)
I am offering writing advice that can benefit anyone writing on a technical topic.
You may have an idea of who your intended audience is, but when you put something out on the internet, you don't know where it will end up and who will read it.
It only takes a few minutes to link terms to their definitions or to write a very short definition.
Your expected audience may not need it, but your unexpected audience will definitely appreciate it.
So if his article were posted on a non-technical forum should he also define what a gui is, just in case? Would it not get extremely tedious defining the basics in every article?
I think it is perfectly OK to have an intended audience and ignore an unintended audience if catering for the unintended audience dumbs your writing down for your intended audience.
It is good writing advice to not clutter your writing with needless explanations.
You have a good point that writing out all your definitions may be needless clutter. It was always a good idea in print, but now we have the web and hyperlinks.
So wouldn't linking to definitions or references make both of us happy? If you're in the target audience you can ignore them, and if you're someone more ignorant, like me, you can click the link to learn more. Seems like a good thing all around.
Technical terms are easy enough to Google. I didn't know the difference either, but that would be my first thing to try before complaining on HN.
At the company I work for, so many things I need to know are internal and so impossible to Google, and even asking somebody usually yields a less than thorough answer. I have to build a picture of how the whole thing works in my head over time. Then I become the resource everybody who is in the position I was before hounds.
Having to Google a term because the author didn't think to include a link is roughly a 0.01 on the frustration meter compared to my current job.
I get the desire for easy and flat interlinking of information. But we need to look at the people who do the work to make that happen as bearers of gifts, not sources of misery. Be the change you want to see in the world, don't just demand others do it for you. Google is your friend.
adding a link is very different to adding a definition. The web is made of links, and linking to the wikipedia article (or other sources) is not only recommended, but encouraged.
Immediate mode and retained mode are not technical jargon in user interface APIs, however, which I the technical audience of this article. I don't think it's reasonable to assume the audience is familiar with jargon from an unrelated field, even if that jargon is in common use in that field.
> I was one of the authors of the "visual" part of Visual Basic.
You must have understood the difference between the VB shape control and the VB drawing commands then, if you wrote these things?
The shape controls were retained and the drawing commands immediate. You could move the shape controls around, but not the drawn shapes after they've been drawn.
The double buffer option on forms (can’t remember the name) was a workaround for a limitation of the immediate drawing commands, where they disappeared when the window was covered and revealed.
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.
From the hip, I'd say one big difference is the API for modals is blocking (waiting for user input), vs callback. That's pretty cool.
I don't yet know how non-modal is handled. Edit: Ah, it looks like return values are also wired up directly, vs the indirection of an event model or listeners. Clever.
--
At this time, I don't think comparisons (in this thread) to OpenGL's immediate ("interactive") vs retained ("batched") modes are relevant.
If you read beyond the first paragraph, you'd learn what the author means by those terms.
The article starts with an example, and then goes on to explain the difference between immediate mode GUI and retained mode GUI is. It is well written and easy to understand article.
What you are asking for is a TLDR at the top of the article. Sure, that would be nice, but on the other hand I don't see anything wrong with writing a blog post that requires reading more than 50 words to fully understand the topic.
> If you read beyond the first paragraph, you'd learn what the author means by those terms.
Ha, you got me there! (I know the HN guidelines recommend to not suggest that someone hasn't read the article, but in this case I'm fair game.)
When I first skimmed the article, I only had a few minutes between tasks at home, so I didn't catch all the details. But since my initial comment stirred up some controversy, I figured I'd better take a closer read. (Well, still kind of halfway skimming since it is getting rather late here.)
In the next to the last paragraph was the clue that made it connect for me: "The OnGUI of Unity Engine actually uses IMGUI mode."
Aha! So this "immediate mode GUI" business is like OnGUI? Where you draw everything from scratch on every frame, instead of the engine remembering stuff for you?
That's when it all made sense, since I had done a bunch of Unity work 4-5 years ago and some of it involved OnGUI().
60654's comment led me to the current OnGUI documentation [1], where they even call it "Immediate Mode GUI (IMGUI)".
I'm pretty sure they didn't use the IMGUI terminology when I was working in Unity, it was just OnGui() with no other special name. Otherwise I would have remembered "immediate mode".
But it's possible that my memory is not as good as I hope it is!
Please use this comment on __projects__. Which fail to include a proper readme or exaplainer instead of a blog article geared towards gfx/game programming
Of course I know what a GUI is. I've been building them for decades, and building tools that other developers have used to build GUIs. (I was one of the authors of the "visual" part of Visual Basic.)
But I have never before seen the terms "immediate mode GUI" or "retained mode GUI". And I'm pretty sure there are many developers like me who will have no idea what you're talking about. It takes only a moment to add a quick definition or a link the first time you mention a specialized term, and your readers will definitely appreciate it. Thanks!
(Edited to remove fluff and make the essential point more clear.)