Immediate-Mode Graphical User Interfaces - 2005

I've long been very unimpressed by common GUI development models. And also by resulting GUIs themselves - typically not very flexible. I've made a few attempts to find better approaches. But the fundamental problem is that in the end one always ends up with a separate state machine for GUI elements - so the GUI has to be synchronized with the state of the main thread. This is hard to get right, and unflexible in the end. Two days ago I came across the "Immediate Mode GUI" approach. It has some following for example in the games or realtime graphics sector. I think it's nice and very flexible, but could imagine it falls flat for complex interaction models where you just need considerable state, and it's better to use conventional widgets which have much of the logic encapsulated: [this video] [link]

As far as I can piece together, Casey Muratori first described the approach in an early YouTube video in 2005: [this video] The basic approach certainly existed far earlier, though. Early "graphical" command line applications, for example, most likely all took an immediate mode approach. It's just that no one thought it was worth making the distinction until after living through the hell that is retained mode GUI programming. In a way, React (along with other vdom-based GUI frameworks) is another rediscovery of immediate mode GUI techniques, but with more of a functional (reactive) programming influence.

Funny you mention this. I used to think the same way, and would constantly trip up managing state, until a co-worker who had worked in video games for two decades introduced me to the concept of the Immediate Mode GUI (IMGUI). Casey Muratori first spoke about IMGUI back in 2005, but didn't actually implement it practically: [this video] In around 2013, Omar Cornut wrote an incredibly high quality practical implementation of Muratori's concept called _Dear ImGui_: [link] Using both Cornut's library and Muratori's mindset is incredibly powerful and liberating. Things that would require days of work and multiple files in Qt or Cocoa can be finished in four hours and a couple of hundred lines of IMGUI code. It also uses an order of magnitude less CPU/memory resources (which was an issue for us as we were rendering and displaying RAW video footage in real-time). I find it amazing that this way of thinking hasn't completely dominated frontend programming by now. There is literally no downside to using the IMGUI concept - entire classes of bugs disappear, and your code is simultaneously smaller, easier to maintain and more logical in flow. It's also a shitload more fun to write (something I think that SWE culture overlooks too much) - you spend the majority of your time writing code that directly renders graphics to the screen, rather than fixing obscure bugs and dealing with the specifics of subclassing syntax.

popular imgui toolkits like dear imgui (fortunately, nobody yet argues that dear imgui isn't really imgui) also actually retain some per-widget state i would say that the key question is whether widget deletion and updating is implicit or explicit; it's a question about how the api is designed, not how it's implemented with immediate-mode graphics like <canvas> or windows gdi, if you update the screen and forget to visit a certain rectangle, that rectangle disappears from the screen. the same thing happens in an immediate-mode gui if you are drawing a window and forget to visit a certain checkbox. both whether it appears or not, and everything about how it's drawn, are guaranteed to be up-to-date with your with retained-mode graphics like svg or tk canvas or current opengl, if you update the screen and forget to visit a certain rectangle, by contrast, that rectangle stays exactly the same as it was before . the same thing happens in a retained-mode gui if you are drawing a window and forget to visit a certain checkbox: the checkbox is displayed in the same way it was displayed before, and it may be outdated with respect to the program data it's nominally supposed to represent omar's explainer at [link] pretty much agrees with the above, though he goes into a lot more detail. similarly casey's talking-at-the-camera video in which he popularized the concept [this video] so it should be apparent that react falls solidly on the imgui side of the line, which is why people use it

imgui is a general approach to designing gui libraries proposed by casey muratori in 02005 [this video] the particular library in question is omar cornut's 'dear imgui' a gui that would use 100% of cpu on an 0.52-mips mac 512 [link] would probably use about 0.02% of cpu on one 2201-mips core of a raspberry pi 3 [link] if you pessimistically multiply that by 32 to account for having 32 bits per pixel instead of 1, and by 12 to account for 1920×1080 instead of 512×342, it comes to 9%. of one of the cores! also it would run in 0.5% of the pi's ram so, to a significant extent, the struggle is no longer to get something approximating your desired user interface running, but to imagine a user interface that's worth people's time to use. so it makes sense to trade off cpu consumption and ram usage for faster experimentation in a lot of cases