#ocornut’s 10-year retrospective on the Dear ImGui library for #IMGUI #GUI
on 02025-10-21#IMGUI #tutorial #toread by “Sol”
on 02025-10-18another #IMGUI #video #toread (by #Tsoding) 84 minutes
on 02025-10-18another #Blow #video with 2h36m on #IMGUI #toread
on 02025-10-18another discussion of #IMGUI pros and cons
on 02025-10-17#PDF slides by Andreas Fredriksson about the game tools he didn’t use #IMGUI for at #GDC17. But mostly about abandoning “Insomniac Web Tools”. There’s a certain amount of “fire and motion” in here: “Disable developer mode extensions. Extensions running in developer mode can harm your computer. If you’re not a developer, you should disable these extensions running in developer mode to stay safe. ... [2016 Surprises] Still firefighting things outside our control. ● Auto-updates: gift that keeps on giving. ● Flash update broke all node graphs over night. ● About a week of engineering effort to drop everything and fix.”
on 02025-10-17why Andreas On Coding (Andreas Fredriksson) didn’t use #IMGUI for his game that he did a postmortem on at #GDC17. “People at Insomniac expect a robust familiar looking UI with good performance. But they also expect a lot of power tools to come with that. Things like: • Filtering and sorting every list and tree view. • Copy and paste. • Multi-selection logic with order preservation. • Undo/redo. • Drag and drop with preview and animation. • Full unicode support (i.e. localization)”
on 02025-10-17Another #IMGUI explanation from 02007, where the non-caching of application state in the GUI library is seen as the main advantage, and DirectX as a crucial enabling technology.
on 02025-10-17nice discussion of #IMGUI comparing dear imgui, with "nuklear" and other alternatives. “at its core immediate mode is about how this state is updated. In classical gui the state of the application was synchronized to the gui state by modification. On the other hand immediate mode is closer to functional programming.”
on 02025-10-17#video of four hours of #Blow on #IMGUI. He’s programming in #Jai and struggling to understand why his UI isn’t doing the right thing. I think this video might be from 02021, halfway through his Sokoban game. In watching frame by frame, I notice that he has one (or sometimes two) frames of lag before initiating mouseover effects (tweened animated fades to brighter colors, etc.) on his IMGUI widgets. (Some of them “breathe” at about 1Hz when the cursor is over them.) Also a frame or two of lag is visible with the mouse pointer when he’s dragging windows. He sure spends a lot of time restarting his game; it takes 8 seconds from recompile initiation to seeing the cutscene, and then by default it plays for a few seconds, though it can be cut short to a single second. if ui.begin(panel, resizable=false) { ... defer { ui.place_rect(0, outer_margin); ui_end(); } ... ui.radio_button(*debug_mode, .Lightmap, *theme); ... ui.separator(); ui.label("Paint color", w=100); ui.same_line(); ui.color_edit(*paint_color, linear=false); ... if ui.button("Swap colors") { Swap(*paint_color, *clear_color); } ... ui.separator(); ui.checkbox("Airbursh", *airbrush); It seems like his .separator() is a small amount of vertical space. For tooltips, ui.hint("Radius of the brush - Wheel"); ui.input_float(*radius, w=64); ui.same_line(); ui.label("Radius");. There are ui.indent(); ... ui.unindent(); pairs for some visual hierarchy, but the indents are very subtle indeed. There’s a ui.enable(bool) for graying buttons out until a ui.enable(true);. The video shows how useful it can be to have video recordings of GUI interaction for debugging; at 43'33” a bug misinterprets a mouse movement dragging a window as also moving a slider, which mystifies Blow, and at 43'57” he erroneously speculates, “Must’ve accidentally dragged that, real fast?” At 45'16” he’s looking at another bug where a “clear” button isn’t being clipped properly and is overdrawing an accordion-control button in its parent. He gets into the implementation arount 54'44”. His definition of “em” is wrong by a factor of 2. He sure spends a lot of time manually doing small table layouts that a sort of elastic tabstops would solve for him. The implementation figures out when to pop up “hints” (tooltips) with rect := place_rect(w, h); over := is_over(rect); update_hint(over); and detects clicks with over && (ui.mouse_button_left_state & .START), and I think place_rect handles moving you to the next line and widening the current line. It’s interesting to hear him using Tk terminology like “entry” for “text field” in 02021. The RGBA color picker is interesting; I thought maybe you dragged up or down from R, G, B, and A buttons to adjust the respective color components, which changes the colors of the buttons to the corresponding primary shade, but in fact they’re just “checkbuttons” that change color when you click them. I like text_height, text_width := text_size(text);. Fading out a border around the window to α = 0 gives a nice cheap fuzzy-drop-shadow-like effect. I feel like for indentation some kind of current-drawing-origin stack might be a good complement to the clipping stack (“scissor stack”, maybe nomenclature borrowed from glScissor). He spends a lot of time debugging problems induced by how Jai’s static type system doesn’t have an Option type for optional parameter defaults. His defensiveness is grating: “The last thing I need is for someone who’s been programming for 5 years to tell me what I do and don’t know.” He’s hashing the addresses of callsites (plus an optional integer for loops) to get unique widget IDs for the IMGUI library. Casey #Muratori pops on at 2'56”, explaining that nowadays he streams his IMGUI drawing commands into a command buffer, sort of like ocornut’s dear-imgui, but higher level so he can run layout algorithms over it afterwards. “The reason I like the command buffer approach is because I like to be able to have more logic in the layout stuff.” Muratori’s definition: “IMGUI just means that you don’t call Create and Destroy on widgets. It means that there’s no need for you, the user, to like record what they are. (...) The core problem that you're trying to solve, and the one that determines whether I call it an IMGUI or not, is, can you just run some code on your side to output the current state of the UI, and you never have to think about whether some previous thing you said will make the UI, like, appear different, right? So you can just say, one pass, here’s what the UI should look like, and that is what the UI will look like.” Blow asks at 3h14m8s: “Was it Sean who used to do the IMGUIs where you would like call the function twice, once with display off and once on?” Muratori: “Yep.” Blow: “Did you ever do it that way?” Muratori: “I think I have played with doing it that way but I don't remember ever liking that.” At 3h19m55s Muratori explains how he did the React virtual-DOM diff and merge thing on his “command buffer” to draw an IMGUI with Qt, pointing out that you could do the same thing with HTML. Oh, at 3h45m50s there’s how scrollable sections work (though it has some bugs where scrollbars don’t show): ui_begin_scrollable_section(*results_scroll_value, w=..., h=...), with presumably a corresponding end call later. He has just a ui.selection_list inside it in that case, which turns out to be a loop calling ui.button for each item in the array which returns the index of the selected button. And I’m amused to see that ui.button is just a call to ui.checkbutton which passes a null pointer for the state, which ultimately calls draw_button with 8 positional parameters, which calls draw_label, which calls text_origin to figure out where to draw the text. Very educational video, even though I think some of the code is kind of naff, like ui_end(false, true). I managed to finish the whole video.
Astoundingly, Thierry Excoffier’s Zero-Memory Widgets #IMGUI library from 02003 still exists and has been updated regularly including up to 02020!
on 02024-09-22#PDF #paper of Thierry Excoffier’s “zero-memory widgets” #IMGUI paper from 02003, LIRIS Research Report 20030311. One neat idea is to disable buttons if the zmw_activated() function is not called while they’re the current widget — if the activation state of the button is not consulted, the library can known that clicking the button would have no effect! I also like if (zmw_tip_visible()) ZMW(zmw_window_popup(&window_tip)) { ... }. I also like the idea of restoring the graphics context state (foreground color, etc.) when exiting a nested widget. #toread
"MicroUI" is a tiny immediate-mode GUI library, 1100 lines of C. It deposits drawing operations into a command buffer for your application to process, similar to dear #imgui.
on 02024-09-09#video of Casey #Muratori explaining #ImGUI
on 02024-08-16"Hyperdiv" #imgui framework (or reactive web UI framework) for Python webapps using chart.js
on 02024-02-21"MicroUI" is a 1.1kloc #IMGUI library in C by rxi, with no dynamic allocation. This version is hacked to run on SDL. It maintains a queue of up to 4096 drawing commands from the library to the app of four types, MU_COMMAND_{TEXT,RECT,ICON,CLIP}, or sometimes maybe JUMP? #small-is-beautiful #noalloc
#Streamlit is an interesting new web app framework similar to #IMGUI
on 02019-12-12“Compression-oriented programming”, demonstrating the process of #refactoring #IMGUI code in the codebase for The Witness.
on 02019-01-27a somewhat polished #immediate-mode GUI library. “#ImGui outputs vertex buffers and simple command-lists that you can render in your application.”
on 02017-04-15A super great 2012 discussion of #IMGUI immediate-mode GUIs and how they relate to #FRP and #reactive programming. Comments from David Barbour (of curl, talking about #ZUI zooming UIs, among others), #neelk, and Sean McDirmid, plus some guy named Thomas Madden who seems to have thought about this stuff a lot.
on 02015-08-10#imgui #dhtml #js #reactive discussion of “Pure UI”
on 02015-08-05“Pure UI” #imgui #dhtml #js #reactive wtf is an Artboard?
on 02015-08-05