Immediate-Mode Graphical User Interfaces - 2005 on HackerTube: recommended by 5 Hacker News commenters across 5 separate months, 2017–2024.
lecture · intermediate · evergreen
Casey Muratori's 2005 video introducing immediate-mode GUIs as an alternative to retained widget toolkits. He explains the motivation and shows minimal-state button logic.
Seen as the origin of the IMGUI idea that inspired Dear ImGui, recommended to anyone curious about immediate-mode UI design.
“Check out this lecture/demo from nearly 20 years ago”
11 Hacker News comments link this video. Each one links back to its thread.
Casey Muratori of handmade hero fame is one of the original pioneers (potentially the first?) of immediate mode user-interfaces. Check out this lecture/demo from nearly 20 years ago: ▶ this video
in “Immediate Mode GUI Programming” · View on HN
ImGui is engine/GPU agnostic Themeing isn't a just a retained mode thing, you can do wonders with immediate UIs, even though (dear)ImGui doesn't provide much, you can still do wonders: [link] The gaming cheating community is quite creative as well: [link] More on that topic: ▶ this video
in “Dear ImGui: Bloat-free Graphical User interface with minimal dependencies” · View on HN
in 2016 Casey Muratori wrote a few words about his old video "IMMEDIATE-MODE GRAPHICAL USER INTERFACES (2005)" -- apparently he'd been using the technique for years by then and had coined the, now commonly used, imgui acronym -- see: [link] and if you dive into that video at 16:50 you'll see a very elegant description of minimal state immediate mode button logic; direct time link: ▶ this video
in “Buttons as Finite Automata” · View on HN
It’s a library for making windows, buttons, etc (called widgets), for windows Linux and macOS. If you’d like to make graphical applications though, I recommend immediate mode frameworks ▶ this video [link] [link]
in “Qt Design Studio 1.0” · View on HN
I will also say that this is not an academic argument for me; I am in the middle of writing yet another immediate-mode GUI right now, for the game editor I am working on. Every day I am freshly glad that I am doing things as IMGUI instead of RMGUI. Here is a (somewhat old) video explaining some of the motivations behind structuring things as IMGUI: ▶ this video
in “VS Code uses 13% CPU when idle due to blinking cursor rendering” · View on HN
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
in “ImRAD is a GUI builder for the ImGui library” · View on HN
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
in “Immediate Mode GUI Programming” · View on HN
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.
in “The complexity that lives in the GUI” · View on HN
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.
in “DearPyGui” · View on HN
ImGui is a fantastic, and much beloved C++ library whose primary use is to create debug/level editor UIs in games, but people use it for many other purposes as well, some of them quite complex. It can plug into various renderers prety easily, and bindings exist for many popular languages, like Rust, and Rust. It was inspired by this talk given in 2005 by casey muratori on immediate mode guis: ▶ this video Neat to see additions like this that can plug into it. The rust joke was on purpose.
in “ImPlot: Advanced 2D Plotting for Dear ImGui” · View on HN
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]
in “McCLIM: A GUI Toolkit for Common Lisp” · View on HN