________________________________________________________________________________
As much as I like Dear ImGui, the immediate mode paradigm doesn't work everywhere. The problem of "page tearing" (not to be confused with vsync) means you either need to render frames continuously, or at least 2 frames for every time you get input or need to implement some kind of "retained mode state tracking" on top of Imgui. It's good for games, but for applications where you're not rendering new frames constantly, the paradigm doesn't seem a very good fit.
I wish there was a retained mode GUI library that would be as easy to integrate in your game and graphics apps as ImGui (or nuklear) is.
On my spare time, I've been working on a retained mode GUI layout and rendering framework (not a complete GUI toolkit) that uses a DOM-like tree, CSS style flexbox layouts and produces a vertex buffer for rendering like ImGui does.
Unfortunately life gets in the way, and all I have to show for my project is a small prototype in C and another one in Rust (can't decide which I like more) that draws some text and rectangles with a fancy layout. Code is not public at the moment but I'm willing to share it with anyone (on GitHub) who responds with a thoughtful comment or a good question.
I have been following Raph Levien's fantastic work on Druid and Rust GUIs which has been very inspirational, this video in particular [0].
Where Raph is focused on native GUI rendering and high fidelity text output, I've only focused on rendering in a GPU application using shaders and only very basic text layout with simple kerning (like Dear ImGui).
As Raph points out in his later talks on the topic, layout and rendering are only half of the GUI puzzle. The other half is maintaining the state of the application, usually through some kind of widget tree.
Leave a comment if you're interested, I'd be happy to chat even though it doesn't seem like my projects are going anywhere anytime soon.
[0]
https://www.youtube.com/watch?v=4YTfxresvS8
Data Oriented GUI in Rust by Raph Levien
Thanks for the kind words. My thinking has evolved since that video; my blog at
is a good place to check.
As flohofwoe suggests in a sibling, combining an imgui-like API with an actual retained widget tree would be something of the best of both worlds. That is indeed pretty close to what the Crochet prototype does. We're not trying to _exactly_ match the imgui but it's pretty close. In particular, getting actions back from widgets (like button presses) is the return value from calling the widget-creating function. That's a notable difference from, say, Jetpack Compose, which is fairly imgui-like on widget creation but pretty much uses callbacks for those actions. Crochet does solve the page tearing problem (though the current implementation is hacky, don't look too closely under the hood).
Another note - the Dear ImGui implementation has become a lot more sophisticated over the years, and is no longer a simplistic implementation of the immediate mode GUI concept. It has unique id's for widgets, its text processing has become better, etc.
Wouldn't it be possible to separate the public API from the internal implementation so much that the library appears "immediate mode" on the outside, but is completely "retained mode" on the inside? With a persistent widget tree which is only manipulated by diffing it against the current frame's UI description provided by the user code?
The important feature of immediate mode UIs is that there's only one sequential piece of code for UI creation, updating and input handling. All I'm saying as the framework user is basically "this is what I want the UI to look like in the current frame".
E.g. if the UI that's described in the current frame by user code is completely identical to the last frame's UI, exactly "nothing" would happen, the internal widget tree wouldn't change, and nothing would be rendered.
Avoiding the burden of a "widget tree" that duplicates application state in complicated, inefficient and error-prone ways is more or less the whole point of reconstructing the whole GUI every frame from data structures that deserve to exist.
Agreed, but in traditional UI toolkits this burden is on the user-side. If the widget tree is hidden away inside the library it becomes just an internal implementation detail, a caching structure which might help make some things more efficient. Proof is in the pudding of course.
_> Wouldn't it be possible to separate the public API from the internal implementation so much that the library appears "immediate mode" on the outside, but is completely "retained mode" on the inside?_
It is possible but you would need some severe API changes... you could either ask the users to use unique names for each widget, or something similar like storing references between frames. Alternatively you'd have to force "same order between frames" (similar to React does with Hooks).
I think the "virtual DOM" approach is more relevant part of React to look at to answer the question. The UI code appears immediate but on each invocation builds a data structure that represents the layout and references to data it depends on. The library consumes this data structure, compares it to its own internal, retained representation and adjusts the latter according to any changes that might have occurred. Input is consumed by the "retained mode" GUI toolkit, which triggers the immediate mode UI to re-render with return values from widgets adjusted according to the "immediate mode" result of the input.
The difference from React would be representational. In React you explicitly build this data structure as something resembling a DOM tree and handle input by attaching callbacks to nodes, but I think this representation is just convenient for web development rather than fundamental to the approach.
You might still need a way to manage updates to the state the GUI depends on and re-render when it changes for some other reason than an input operation.
Dear ImGui already uses such "implicit" widget ids, by default it hashes the widget's label string, window title or name, with a convention to add an invisible 'identifier string' to the label string separated by a "##" (e.g. "Label##id") - for the case that the visible label string needs to change or isn't unique within the current scope. There are also separate PushID/PopID functions to manage such widget ids in "more elaborate ways".
This also has been one of my biggest gripes with "imgui" style of libraries - as the end of the day something needs to keep state somewhere, and implementations/hack can be very language/runtime oriented to avoid hacks like above, or use the hack above.
It also caught me by surprise, and would catch many others where seemingly normal controls, that just happen to have the same text would be identified with the same state, as the text (contents) are initially used to point to this state.
Interesting, I didn't knew that. I helped write a couple immediate-mode GUI some time ago, but I'm not deeply familiar with ImGui.
If this is the case, then it seems entirely possible to have an "internal retained mode", and might even help with some extra stuff like focus management and accessibility.
Hi, I'm making SkyAlt[0]. It's IDE and language for building applications. Probably I did something right in the beginning, because It doesn't have problems with "page tearing", but it's true that It does "state tracking" in the background.
Feel free to check my blog and send me an email if you are interested. I have work in progress version for Windows and Linux, but no documentation yet. It will be released(free and open-source) by end of this year.
[0]
You will always get page tearing with ImGui (this library and any others). There are mitigations and workarounds but the issue is fundamental to the paradigm.
Consider this trivial counterexample:
int counter = 0;
label("count: %d\n", counter);
if(button("increase")) { counter += 1; }
label("count: %d\n", counter);
This is, of course, a silly little example but the same issue will arise in many practical use cases and would be much more complicated.
Most applications "solve" this by rendering new frames continuously, so the inconsistent state is only shown for one frame and will quickly disappear. This, however, has terrible power consumption implications if nothing of interest is occuring on the screen.
Sorry, I thought that "page tearing" is something else. For example that It has to decide if the scroll bar will be drawn or not. And it has to make that decision before it starts drawing layout items because there can be an item which expands from left-side to right-side(dynamic layout), so the finalLayoutWidth = originalLayoutWidth - scollBarWidth. Then it can compute item's sizes and draw them. My solution is to save maximum layout size from previous frame.
SkyAlt would "solve" your example by quickly redrawing the frame. The power consumption is good because it's redrawing only when the key is pressed or the mouse is moving, otherwise one frame every two seconds, so CPU is most of the time under 1% and my 3.6GHz CPU is running on 1.4GHz.
That looks more like coupling the state with the UI. You could try refactoring your code in an MVC/MVVM style like react such that the state isn't being modified during a UI draw. That sort of out-of-sync issue can happen even with retained mode UIs. I wouldn't say it's fundamental to the paradigm that you intersperse your business logic into your UI. Granted at large scales basically any UI framework falls apart.
That's how normally you write "imgui" style of app - that's the whole idea - you on purposes couple state+behavior+ui in one piece - e.g. if(checkEvent()) drawSomething(); else drawSomethingElse();
Two label that should have the same value are normally one too many, but if they are needed it is often possible to order them properly...
//initialization
int counter=0;
//each frame
label("count: %d\n", counter);
label("count again, in case you missed the other label: %d\n", counter);
if(button("increase")) { counter += 1; }
or, if the order of widgets is constrained, to buffer values:
//initialization
int counter_old=0;
int counter_new=0;
//each frame
counter_old = counter_new;
label("count: %d\n", counter_old);
if(button("increase")) { counter_new = counter_old+1; }
if(button("decrease")) { counter_new = counter_old-1; }
label("count again, in case you missed the other label: %d\n", counter_old);
So this is complexity you normally don't need with other UI approaches. And now would become a "pattern" that needs to be followed.
Have you considered developing using an IDE like Lazarus but with extensions allowing the component library to use Imgui instead of the default Lararus components?
I heard about Lazarus, but never tried it. I'll give it a shot.
_It's good for games, but for applications where you're not rendering new frames constantly, the paradigm doesn't seem a very good fit._
It's also very inefficient to continuously redraw, which is not a concern for games, but not in general.
The vast irony of all this is that today interacting/scrolling in Facebook or Twitter is vastly less efficient that a basic graphic app rendering at 60 FPS. Facebook has become _ACTUALLY_ slow to interact with even from a human point of view.
This is a very common problem on modern machines and modern software. Engineers default to putting in so much machination of caches and dirty-flags to avoid redundant processing that they end up making something that does way more work to avoid work than a decent implementation of just blindly doing the work all-gas-no-brakes.
I’m not entirely sure this is true in practice.
Games can render huge, vibrant, dynamic 3D worlds at 60fps and increasingly at >120Hz rates. Web browsers lag if a piece of dust falls on the wrong spot.
I agree with you in theory. But in practice retained mode is a mountain range or complexity and doesn’t actually perform better.
Games also require said GPU computing power. Lots of UI may have to conserve power/energy - think about some IoT device that may not even have GPU, and need to use as little as possible energy.
Or smartphones where you want to conserve battery life.
I think people dramatically overestimate the cost to perform simple UI layout. There’s no reason that CPU time should be more than 1ms single-thread for most apps. GPU time should be similarly small. Modern smartphone supercomputers are FAST!
I'm not convinced that redrawing on input events is especially inefficient. No need to redraw continuously.
Indeed, I've got dear imgui working like that and it's the performance is miles above any retained gui. Dear imgui however it is not designed with this in mind. You run into a some issues with timing, handling release events and a few things which normally take 1-3 frames to fully resolve. Things like key repeats are off. It feels more desirable to fork the lib or design an alternative imgui to support long periods of idle time.
Imgui has problems, but this isn't one of them.
Your retained-mode GUI framework isn't doing dirty rectangles anymore _anyway_; it's going to redraw everything anyway. (Not every frame, but upon receiving an event.) With modern GPUs, redrawing a whole frame is _super cheap_, even with integrated graphics.
The gain, then, is going to come from not having to rebuild the scene graph every frame. And modern imgui implementations will cache the scene graph+layout anyway, and only rebuild the parts they need to. Which is _slightly_ more CPU-intensive, but not appreciably so.
> Your retained-mode GUI framework isn't doing dirty rectangles anymore anyway; it's going to redraw everything anyway. (Not every frame, but upon receiving an event.)
Except that a a retained mode GUI can easily tell that no redraw is necessary and it will be a no-op.
> With modern GPUs, redrawing a whole frame is super cheap, even with integrated graphics.
It's cheap as in fast, but it's not cheap in power consumption having to wake up the GPU from sleep state to redraw what's already on the screen.
This matters with battery powered devices.
> The gain, then, is going to come from not having to rebuild the scene graph every frame.
Rebuilding a scene graph that's based on CSS-style flexbox layout is REALLY fast. It's a linear time operation in the worst case and a lot of the work can be just skipped if the layout doesn't need updating.
Check out Raph Levien's talk which I linked to in my top level posting. He discusses the implementation details to make this smoking fast.
Text layout is by far the most time consuming operation in rebuilding a GUI scene graph.
The way this is done in the Druid UI library is probably a lot faster than what ImGui does, if you exclude the time it takes to do text layout with HarfBuzz.
All of this is pretty moot point, because the most important factor in performance and battery consumption is not to wake up the GPU to do unnecessary work.
> Except that a a retained mode GUI can easily tell that no redraw is necessary and it will be a no-op.
How is that different from imgui exactly? Both dirty rect invalidation and the following redraw skipping is incredibly easy to do (and has been done, see microui)
> Rebuilding a scene graph that's based on CSS-style flexbox layout is REALLY fast. It's a linear time operation in the worst case and a lot of the work can be just skipped if the layout doesn't need updating.
I'm not sure what are the numbers there, but my fullscreen imgui application (You can see it here
https://twitter.com/DoctorGester/status/1022147094558269446
and there are views with more complex layouts, rich text rendering, etc) hacked on top of DearIMGUI takes 0.2ms (200 microseconds) per frame, that is including all the logic and submission of commands to the GPU backend. That's before any optimization or multithreading independent views. Do you really get much faster than that?
> Your retained-mode GUI framework isn't doing dirty rectangles anymore anyway; it's going to redraw everything anyway.
Does this refer to the one presented in the top-level comment or a retained-mode GUI framework in general (like GTK)? Because it's usually not true for the latter.
i plan using it in a data viz app. works great! much better experience than traditional GUI toolkits.
Videocards redraw every frame anyway.
_> The problem of "page tearing" (not to be confused with vsync) means you either need to render frames continuously, or at least 2 frames for every time you get input or need to implement some kind of "retained mode state tracking" on top of Imgui._
Suppose that the widget functions apply one of two different strategies depending on the call context: 1. Render the widgets and 2. Evaluate the layout and process input accordingly. You invoke the GUI code in the second context on every input, and after that invoke it in the first context only if the calls in the second context potentially resulted in a change. This minimizes re-rendering and eliminates page tearing while allowing you to re-render reactively to events.
You will of course still need some kind of basic state tracking to make the GUI re-render to reflect changes that are not triggered by input.
In general, I agree, though. The right tool for the right job.
> As much as I like Dear ImGui, the immediate mode paradigm doesn't work everywhere. The problem of "page tearing" (not to be confused with vsync) means you either need to render frames continuously, or at least 2 frames for every time you get input or need to implement some kind of "retained mode state tracking" on top of Imgui. It's good for games, but for applications where you're not rendering new frames constantly, the paradigm doesn't seem a very good fit.
Writing a desktop app using ImGui I had the same problems. In many instances it can be resolved by re-ordering operations such that in a frame you first update the state and then render it, but this isn't always possible or easy. For those cases I eventually resorted to having a requestFrame() function (which posts an empty event to the input queue at the end of the frame, causing another frame to be rendered immediately).
It's exactly these cases, where I'm not really comfortable moving away to imgui, say from Qt (not that I like it a lot), but there has been pressure at work to do so...
Can you explain what "page tearing" is?
I think it refers to the fact that in an immediate mode GUI you adjust the application state while you render the page, meaning that the part of the screen which you rendered before the state was updated shows the old state, while the part of the screen which you rendered after the state was updated shows the new state. The screen is basically "torn" between two or more states and you need to draw another complete frame to bring it back in sync. Not a problem in a game where you redraw everything at 60fps anyway, but not so good for a classical GUI toolkit.
Edit: I guess you could partially solve this problem by double-buffering the application state, so during the first draw you update a state copy, and during the second draw you use the updated state. You won't get any "tearing" but you still need to draw twice.
I use ImGui for gui in a user-facing app that is "large-ish" (~500k LOC maybe). When removing items from lists etc I used to keep drawing non-removed items in the list so the user would not see a "glitch". But I realized it is not necessary. Just cut it short. The user can only take one action per frame from mouse click or button press etc. It's totally fine to render one frame a bit "strange" when someone deletes or adds to a list.
There is no problem in redrawing everything from state every frame. There is no problems in having "half frame be old state" - even at 30 fps it is not noticeable.
We use a separate update() and gui() path though. So all entities will get an update opportunity even if the gui is hidden. And state is kept in a config that is beautiful to use... Maybe the issues here comes from not having those parts.
I think their point was that you can't do this without committing to redrawing all the time at a reasonably high rate, which has its own set of problems.
Like if you have to concatenate string to make labels (and then parse and measure and format and re-flow text), you end up generating a lot of garbage and memory management and pointless recalculation in the main loop.
Yes, for sure there is some overhead in this. I checked in Tracy now and with a lot of gui open, using many custom labels etc, it takes on the order of 150-200 us to do that part of the gui. Issuing the GL draw list commands takes some time too, but not too much. I think the expectation is that it is expensive for real, but it turns out that ImGui is actually quite cpu-time-cheap. And a "modern" electron based app gui has a whole different set of overheads, so it not like all alternatives are overhead-free wonderlands..
Sorry if this comment sounds a lot like "why don't you just"-ing, I'm just trying to understand what I'm missing and I don't expect to be right.
But is rendering twice really that much of a problem if you only have to do it on a state-changing event (even if that includes things like hover events or live data)? Even games that run with 30-60 FPS aren't really a problem anymore on weak hardware so why would a GUI that updates "once in a blue moon" (relatively speaking) be?
Apart from that, I don't know how Dear ImGui or other immediate mode GUI frameworks do it but if a framework handles page tearing with double rendering it could skip the actual paint (i.e. pixel drawing) in the first render. In case the user wants to avoid some needless work (like rendering labels or graphs that never affect state) in the first render the framework could also pass the calling context (update or paint) to the render function.
Maybe it is still VBL related, in the DX11 sample you will see this when presenting the final frame:
g_pSwapChain->Present(1, 0); // Present with vsync
//g_pSwapChain->Present(0, 0); // Present without vsync
So you can control this by setting the first argument to 1 or 0.
It's not related. The "page tearing" problem is caused by the way imgui handles events.
You describe the UI by making a bunch of function calls, each of which immediately renders a piece of the UI _and_ returns any relevant events (e.g. render a button, return whether it has been clicked). But this means that any event that should change how the UI is rendered may have missed its chance- what if the changed part of the UI has already had its function called that frame?
The "ideal" dataflow, as far as this problem is concerned, would be to fully process all the events in a frame (from raw input, to widget-level events like button presses, to application-specific stuff) _before_ rendering anything.
How about this one:
https://github.com/cycfi/elements
?
You can't implement a user interface editor, or user editable interfaces, with immediate mode guis. You can't load and save user interfaces out to resource files, or dynamically generate user interface resources from other programs. You can't iterate quickly on user interface development, because the user interface specification is a program that you have to recompile, not data that you can reload.
That's not true.
One of the benefit of IMGUI-style is to simplify user-data binding and avoid user-data sync/duplication, but that's entirely decorelated with layout consideration. You could perfectly have an editor manipulating widgets properties or their layout info (e.g. pos/size/anchor) somewhere and have the function fetch and use those infos.
If a widget exist in an user interface editor, regardless of the UI paradigm, some code will interact with that widget (read/write the data or bind actions to some callback). So what are you describing and what exists everywhere are merely a way to edit properties and layout, which can be done in IMGUI style, and actual binding requires code either way.
> or dynamically generate user interface resources from other programs.
Err... of course you can, and you are free to express them in whichever format is more adequate and convenient from your application. Generating user interface resources doesn't mean "generating code", that would be silly because the interesting part of that code is the data/function binding, and that's the one that makes less sense to magically generate.
> You can't iterate quickly on user interface development, because the user interface specification is a program that you have to recompile, not data that you can reload.
Then I'm sorry for you if recompiling and reloading code is a slow process in your workflow today. Many languages including C++ have hot-reloading techniques, and it is the standard for any so-called "scripting" languages like Python, Lua, Javascript to be easy to reload. _Because_ IMGUI have less state and less spread editing UI touches less code, less data structures, less layers and therefore it is easy to have that dynamic editing. With Dear ImGui I can add temporary tooling UI _inside a random function deep into the callstack_, reload the code while running, then remove that code when I'm done.
When you say we can't, it might be prudent to specify that "It's not a mainstream/simple feature" instead of "It's impossible"
Well, of course it's _possible_: The widgets can be stored in a tree-like data structure, which is constructed and modified by the UI editor, can be loaded and stored in a file, and is interpreted by a runtime which calls the corresponding widget functions ooops we've just reinvented retained-mode GUIs.
Not sure why this is showing up on HN today. But Dear ImGui is absolutely amazing. And its not just for C++. I use it myself in my C# game engine. (There's a C# port that uses System.Numerics:
https://github.com/mellinoe/ImGui.NET
) which I've ported to MonoGame
https://github.com/roy-t/ImGui.NET
)
I've used a lot of different UI frameworks (winforms, WPF, Html/CSS based frameworks, custom game engine frameworks). But for prototyping Dear ImGui and the whole immediate GUI idea is amazing. It even looks quite decent and the new docking support is great :).
The Dear ImGui C++ API also maps very well to C, so well that I actually prefer the C-API when working on a project that's mostly C (instead of using C++ for the UI code and C for everything else as I did before). AFAIK most of the other language bindings are also based on the C-API (which is autogenerated from the C++ API):
https://github.com/cimgui/cimgui
We recently started to use Dear ImGUI in our custom game engine. Before we used Unity which has its own immediate mode gui solution.
And I have hard time to switch. I don't know if I don't understand how Dear ImGui work yet in comparison to Unity's one but it feels so limited.
So main difference is that Unity is multipass (it calls your gui drawing code multiple times per frame) and because of it it supports horizontal layout, vertical layout, custom layout modifiers, styles and it is easy to use
in Dear ImGUI I am struggling to write stuff like:
layout 3 controls horizontally, allocate fixed size for first and last one and use all left space for middle one
or
layout next N controls vertically of unknown height and use this background color for them, then layout another set of controls and use different background style for them
I am not the person who was actively working on integration it into our engine, so maybe it's the problem of not having documentation on our wrapper...or me not understanding very basics of it
Talk to occornut! He even posts here. Surely you gonna get some reasonable reply, or at least something. Also consider supporting him! Raise an issue on github, or look for similar before hand. I'm also torn when comes to dear imgui, but keep reading updates on it, and trying it at least few times a month with small things.
honestly, im pretty sure imgui can't help you here, i.e. you have to calculate all the necessary sizes/positions yourself and tell imgui where everything should be
Cool. Does that mean I can use this in a C# Console app?
Every couple months I browse the screenshot threads
https://github.com/ocornut/imgui/issues/3488
Looking at them makes me really happy for some reason.
Agreed. These look fantastic, and has been the driving force for folks around here to want to change to that. I just don't know what to expect once we go that route (certainly intrigued, also occurnut is one of the nicest and most responsive people around). We have large 3d level editor, and there has been talks about us trying imgui with it. Slowly moving it out of Qt maybe? There is lot to like now in imgui - especially now that there is proper docking :)
IMGUI is good on many levels, but also has some serious drawbacks. Specifically: latency in figuring out exactly how big a control or layout will be. This also translates into at least 1-frame latency when drawing to a widget based on user input. Imagine a scrubber line on a video timeline or graph, for instance.
Non-immediate mode GUI (retained-mode?) means that you can query a layout for exactly how big it will be before it gets drawn. So, if the user clicks at say (100, 200), I know exactly where to draw something in response to that click on top of my widget, without waiting a frame for the GUI to layout.
Maybe developers who have come up in the web world don't care, but I find reflow issues to be one of the worst features of browser apps. If you're going for a tight native experience, then this is a huge no-no.
The "immediate-mode" GUI idea was something that Casey Muratori, a very influential indie game developer, came up with. Part of his rationale was that it was annoying to store all the state for your widgets in a parallel data structure to the widgets themselves. So why not just draw the widgets, as needed, where you have the local variables and data to draw them?
Various developers and frameworks seem to get smitten with this idea, jump on the bandwagon, and then run into the flaws. For a long time the Unity game engine followed this model. I found the GUI easy to get started with, but ultimately limiting. Unity eventually abandoned this approach.
Really, this is good for developer-quality in-game debugging UI, but it's not a great approach for creating polished end-user UI.
I adopted IMGUI, used it briefly, was impressed by its speed, but ran into massive problems customizing controls to get exactly the right look and feel.
My take -- this is an ideologically-driven kind of neat but ultimately dead end. Use it to quickly get a dev GUI going, but it won't see you through to a polished consumer-ready GUI.
There is no reason an IMGUI cannot efficiently construct a hierarchy in the background and do a fast Flutter-like linear layout pass on it before processing input and rendering it. Then throw this away and do it all over again for the next frame (or the next time input arrives, if not used in a game-like context). I've experimented with this, and speed is no impediment if implemented correctly.
IMGUI is about the immediate mode interface, not about layout/rendering/input handling happening at the same time as view functions are called.
And don't do "if (Button()) { ... }", but use lambdas for event handling, so the handlers can be invoked at the proper time when everything is laid out.
I guess? But the neat thing about IMGUI is how easy it is to integrate and get up and running without having to learn much. Like dump this thing into my code in 1-2 hours then get back to what I was really doing. With the accommodations you mention, you lose all of that and still don't end up with something as functional as say Qt.
This is the definite TLDR on how layout/constraints in flutter works -
https://flutter.dev/docs/development/ui/layout/constraints
I don’t exactly understand argument about frame rates, I thought these GUIs ran at very high frame rates and 1 frame wouldn’t be perceptible by humans. Is there really a human perceptible significant latency with them?
There are a lot of hidden traps when rendering _anything_ on modern operating systems that add small latencies and those small latencies add up quickly (it was much easier on old 8- and 16-bit computers).
For instance rendering something that "sticks" to the system mouse pointer and doesn't lag a few pixels behind when moving the mouse is surprisingly hard if you're rendering through a 3D API (compared to going through the native window system), at least if you also want to be energy efficient (e.g. not spam 1000 frames per second).
What strikes me as odd is describing the ImGui idea as an "ideology" when it's the most pragmatic way to describe user interfaces in a long time, for me that's the opposite of an ideology.
I think if it as Casey Muratori's "brain fart" that made sense in his context but that other developers have latched on to because of his influence in indie game circles.
I have massive respect for him, and followed everything he did back in the late '90s and early aughts, but he's quite opinionated and has some peculiar code aesthetics / trade-offs.
I first got introduced to the concept by his talk, and this implementation here -
http://sol.gfxile.net/imgui/ch01.html
(latest archive I could find -
https://web.archive.org/web/20200428143845/http://sol.gfxile...
)
I've did some translations of the above C/C++ code to lua longtime here (actually luajit, as it requires the FFI) -
https://github.com/malkia/ufo/blob/master/samples/SDL/imgui/...
(simplest example) through
https://github.com/malkia/ufo/blob/master/samples/SDL/imgui/...
though my hack for C/C++'s __LINE__ macro was
local function GEN_ID()
return CURRENT_LINE()
end
e.g. you basically tie the state to the... ahem.. source code line (you need really something unique). Obviously Dear ImGUI has better approaches there (use the widget's contents, like text/label contents, or add your own with ##).
Anectodal etc etc, but when I started using Dear ImGui a few years ago I had no idea about the origins of immediate mode UI, or what "immediate mode UI" even means, and neither had heard of Casey Muratori nor Omar Cornut.
All I saw was a very enjoyable way to create UIs, something I loathed before (like most other programmers I guess). So far I haven't come across another UI toolkit which is as enjoyable to use as Dear ImGui (and that includes a couple of other ImGui libraries), and that's the reason why I stick to it, not because of some sort of cult of personality ;)
I think if it as Casey Muratori's "brain fart" that made sense in his context [...]
I have massive respect for him, [...]
Sure doesn't sound like it. You're so dismissive of others' ideas that I don't even feel like you're looking for a constructive discussion.
Not sure why you would conclude that from what I wrote. I see myself as adding historical context + usage experience.
EDIT> I've learned a bunch from this discussion, and I haven't directly refuted much of it, just added commentary.
Dragging around a pointer, or scrubbing a line will be noticeably laggy with > 0 frame delay. It leads to a sluggish feeling that may be okay in the web world, but is kind of against the whole aesthetic of performant native apps. What's strange to me is that Muratori is a _huge_ stickler for performance, like Jon Blow. I can't imagine him being happy with any kind of lag.
Cursors are done with hardware cursor sprites on the video card and so run perfectly at the full frame rate of the monitor. In game cursors will be different.
Let's say you're dragging something at 3 cm/s. Rendered at 30 Hz, a one frame latency translates into 30/30 mm which is 1 mm. A 1mm gap between the cursor and the thing you're dragging is definitely perceptible, and this is for a relatively slow drag. It's at least enough to destroy the illusion that the thing is locked to your cursor.
> Part of his rationale was that it was annoying to store all the state for your widgets in a parallel data structure to the widgets themselves.
That is only a problem if you don't have closures (for callbacks) and dynamic and generic data structures (like json and polymorphic object references, that you can attach to generic widgets without having to subclass them).
This library is called Dear ImGui. Please refer to it as Dear ImGui (not ImGui, not IMGUI).
(The library misleadingly started its life in 2014 as "ImGui" due to the fact that I didn't give it a proper name when when I released 1.0, and had no particular expectation that it would take off. However, the term IMGUI (immediate-mode graphical user interface) was coined before and is being used in variety of other situations e.g. Unity uses it own implementation of the IMGUI paradigm. To reduce the ambiguity without affecting existing code bases, I have decided in December 2015 a fully qualified name "Dear ImGui" for this library.
Yes, but why "Dear"? Makes it read in an odd way wrt to idiomatic English.
I would guess, since it has been rebranded on christmas day, that it's named Dear ImGui because when you would write a letter to Santa Claus, you would start by "Dear Santa" (or at least in french, "Cher père Noël").
Maybe a parallel is to be made between the library and Santa Claus, because if you ask for something kindly, you would magically have it, without it being cumbersome for you.
In fact, this is conventional for letters in general-- not only to Santa, and not only in French.
> Yes, but why "Dear"? Makes it read in an odd way wrt to idiomatic English.
And "ImGui" does not?
I actually love that - it's very personal, fun, loving, something that you've endured and made it happen. Simply love the naming. Just "imgui" is not going to make it, although "imgui" now is mostly associated with exactly "Dear ImGUI".
the owner is french, I bet the french "cher imgui" reads better.
> _the owner is french_
Think, for _#dearMoon_[0] name "dear" refers to Jules Verne's "Rocket to the Moon".[1]
[0]
https://twitter.com/dearmoonproject
[1]
https://en.wikipedia.org/wiki/Jules_Verne%27s_Rocket_to_the_...
No, it does not.
One of the most valuable parts of Dear Imgui is the example applications, which are great as a reference and starting point for your own projects. Many different platforms and rendering APIs are covered.
Also be sure to check out the 'docking' branch, which implements docking panels and tearaway windows in the style of Visual Studio. There are many low quality versions of this concept in other GUI libraries but I think Dear Imgui's version is the best I've seen outside of Visual Studio itself.
Happy to see ImGui trend here on HN!
It is an amazing tool that is used in a lot of game engines for making internal/dev gui:s. The principle of drawing gui "as you go", interleaved with control flow makes it easier+faster to make gui:s.
In our company's main app we use ImGui (with customizations) for all gui work (from C++ and Rust).
I work at one of the largest games publishers out there and I'm pretty sure ImGUI is integrated into all of our games at this point during development for debugging. It's an absolutely fantastic tool.
Oh, we do actually sponsor it:
https://montreal.ubisoft.com/en/ubisoft-sponsors-user-interf...
Nice :)
Will you use it for user-facing gui:s, looking forward?
As much as I love Dear ImGUI it's arguably not a good UI for user-facing apps (vs dev team apps)
Supporting all of unicode, all IMEs, emoji, right-to-left languages, etc. is arguably out of scope for Dear ImGUI.
Well, maybe. We use it user-facing for suite of niche vr/tele-op applications and it works wonderfully. We have support for Korean, Japanese, Hebrew (serious issues with right-to-left in our implementation though).
The thing about ImGui is it puts devs on steroids - adding gui is just sooo fast. And fun. And easy to tweak. And easy to debug. 10X, maybe?
I get that for a game maybe the user facing gui is less of an issue - it needs to be really polished and maybe there isn't as "much" gui anyway? But for indie-games and productivity apps, it seems like having a gui option that offers 10X faster development - wouldn't that be really convincing? Even if it isn't 10X, maybe only 1.3X, it still seems like it would be easy to motivate some missing functionality. And I would argue it is way more than 1.3.
And looking forward - IME, emoji, right-to-left: those are just PR:s waiting to be written :)
I'm incredibly bullish on ImGui paradigm. If programmers gravitate towards it and prefer it as much as they do then there is some real power there.
The only bad thing about ImGui is that the Rust port of it... well... sucks. At least the way it handles strings at the moment. Then again I always found Rust's handling of strings to be one of the negatives of that language.
i am so curious about your use of colon to pluralize initialisms (which i've always found awkward to pluralize, especially in lower case). is that cultural? an intentional choice?
Well - it just looks right to me... As a non-native English speaker I’m probably wrong about it, but compare these:
- guis
- gui’s
- gui:s
Top looks like French. Middle looks like like the gui is owning something. Third is clearly the right choice :)
- GUIs
Yes, ok, maybe that is correct, but why are you screaming?
Profile mentions .se. Swedish keyboard layout, meant to press apostrophe, still had shift held from writing R, then by accident pressed key to right of apostrophe to obtain colon?
On further thought this works similarly for US layout.
Very unlikely, I don't really see why we would. All of our engines have their own extensive UI tools that can be used to create rudimentary interface very quickly if needed. Maybe if we ever released like a level editor or something, but I'm not aware of any such thing right now.
This is neat, but the problem I always had in these type of libraries is that they only work enough for the examples to be usable. As soon as I wanted to do something that was not in examples, that would either won't work at all or needed a horrible hack to work. I can't give a real example from the top of my head, but I am thinking like the examples would not show how to do a modal popup window and then you learn when you try to instatiate such window then the other window goes crazy or if you close the modal window everything closes and there would be no way to fix it other than digging into library code.
I hope this one is not like that.
Dear ImGui is not some half-baked experiment. It's used in tons of real world projects right now. The main way I've seen it used is for developer-facing GUI (debug views, tool/editors, etc)
Did you read far enough in the readme to see the screenshots of the projects using this already? Those look like very complex UIs, and at least one of them is open source for you to look at.
It looks very impressive indeed! I may be giving it a go in the near future as I may have an use case for it.
I agree. They work fine for simplistic interfaces with a few buttons, but what about more complex widgets, like plain/rich/code text editors, that have a lot of different callbacks and fire many different asynchronous events?
Sure, a button function that returns a boolean can be used as a simple parameter to an if statement, but you would would need a switch statement to test for all the different events that a text editor could send. That's a terrible clumsy API! And where do you store the complex state of the attributed text, or parsed source code in a code editor? Do you just pass the entire string in every frame and re-parse html each time?
Where do you store and how do you access all the hidden state, like keyboard focus, cursor position, editing modes, etc, that object oriented user interfaces simply expose as properties, getters or setters?
And how do you implement an outliner? Do you have to write recursive immediate code that traverses the entire tree every frame? Where do you store the outline opened/closed state, per-item state, and the cursor position?
You can't just store that state in the actual objects you're showing in the outline, because that mixes your user interface layer with your data modeling layer. The cure is worse than the disease. You end up cobbling together your own spaghetti-coded special-purpose object oriented retained mode adaptation layer, just what you were trying to avoid by using immediate mode in the first place.
And how do you implement efficient scrolling lists or tables or spreadsheets containing thousands or even hundreds of thousands of items? Do you have to pass every single item through the API every frame, instead of implementing callbacks to only pass and cache the items that fit on the screen?
And how do you implement graphics editors? Or drag and drop previewing? Or popping up item specific menus and submenus when you right-click on a list or outline item? Or anything more complex than a simple button?
Objects and closures and asynchronous event handlers are the best thing that happened to user interface programming since the pixel. Use them!
You ask a lot of questions, but none of them are sincere.. Especially since you finish it off with a dogmatic "Use them!". How about keeping an open mind, asking real questions, and give others the chance to prove you wrong (which would be beneficial to you if they succeed)?
IMO you're so stuck in the OOP mindset, that you cannot see the very simple solutions to your questions. To just pick a single example out of the many, since you don't seem to want to be proven wrong anyway..
_Where do you store and how do you access all the hidden state, like keyboard focus, cursor position, editing modes, etc, that object oriented user interfaces simply expose as properties, getters or setters?_
In OOP each single widget would store whether it is focused using some boolean member. In IM GUIs one just stores the ID of the widget that is focused once in some library-local data structure:
// ui.h
bool has_keyboard_focus(uint64_t widget_id);
// ui.cpp
struct UIData {
uint64_t focused_widget_id;
int16_t cursor_x, cursor_y;
} ui_data;
bool has_keyboard_focus(uint64_t widget_id) { return ui_data.focused_widget_id == widget_id; }
// my_widget.h
EditMode my_widget_get_edit_mode(uint64_t widget_id);
// my_widget.cpp
map<uint64_t /*widget_id*/, EditMode> widget_id_to_edit_mode;
option<EditMode> my_widget_get_edit_mode(uint64_t widget_id) {
auto itr = widget_id_to_edit_mode.find(widget_id);
return itr != widget_id_to_edit_mode.end() ? itr->second : std::nullopt;
}
> Sure, a button function that returns a boolean can be used as a simple parameter to an if statement, but you would would need a switch statement to test for all the different events that a text editor could send. That's a terrible clumsy API!
Yes indeed, it would be stupid for a text editor to force you to react on one million events or state changes. But this not how text editors are used. To use text editor in most case you only care about the text contents. Any other information is opt-in.
> And where do you store the complex state of the attributed text, or parsed source code in a code editor? Do you just pass the entire string in every frame and re-parse html each time?
You store it wherever you'd store it normally. Many of your question are assuming - and it's a misunderstanding - that IMGUI means that everything HAS to be recomputed every frame. What matters if the interface presented to the UI programmer. Of course the non-trivial text editor requiring a heavy parser, is going to store data if it needs to do so. What's the problem? Did you expect that IMGUI used zero-byte of memory and never store anything?
Text editor:
https://github.com/ocornut/imgui/wiki/Useful-Widgets#text-ed...
> You can't just store that state in the actual objects you're showing in the outline, because that mixes your user interface layer with your data modeling layer.
Ever heard of data structures? You can associate data to an object given its ID without storing data inside the object.. This is what practically any advanced widgets in IMGUI land work. If you need 1 piece of data, use a dumb containers, if you need N pieces of data, use a map.
> And how do you implement efficient scrolling lists or tables or spreadsheets containing thousands or even hundreds of thousands of items? Do you have to pass every single item through the API every frame, instead of implementing callbacks to only pass and cache the items that fit on the screen?
You use a function call helping you to submit only items that fit on the screen. There's literally a helper for that in dear imgui.
At this point I'm assuming you have never used what you are criticizing.
> And how do you implement graphics editors?
https://github.com/ocornut/imgui/wiki/Useful-Widgets#node-ed...
> Or drag and drop previewing? Or popping up item specific menus and submenus when you right-click on a list or outline item?
That's widely shown in the demo.
I like ideas behind immediate mode gui. It's a bit like React.js only without DOM in between. It's not ideal, it has its own issues, but it could develop further into something more robust, I hope.
GUI is hard.
- the developer is the creator of MEKA, a (1998!) Sega Master System emulator, which had the reputation to be the best during a long time (and still may be, I don't know anymore)
- WonderBoy Dragon's Trap remake and Street Of Rage 4 for PC/consoles, it's him too
I may be wrong, but following the screenshots, the Dragon's Trap development was like : we need tools to write a game ! let's write it ! Wait we need libraries to write tools ! let's write them !
The quality of the game and all the details reflect impressive skills and amount of work.
I haven't properly thought this through but is here a sense in which the React "one way data flow" paradigm is a case of rediscovering immediate mode GUIs on the web?
IMHO there's a lot of overlap between the reactive UI philosophy and the immediate mode UI philosophy. The main difference is IMHO that React is "mainly data" while IMGUI is "mainly code". But code is data and data is code, so... :)
I love it until I have to do modals..
Dear ImGui is excellent and is very handy to make GUI version of a CLI app especially if we want to interactively set values and see results.
It is fairly low level (deliberately) and that’s great to keep it simple. I wish there is a standalone GUI ‘framework’ which builds on these primitives and leans on standard library to make the experience a bit more nicer when building standalone applications.
I understand this is not the goal of Dear ImGui. I may give it a shot in a few months time if I don’t come across any such project.
Widgets are bloat.
Is there a similar library but without widgets? Something really, really simple. I just want a canvas to draw, and a handler to receive mouse and keyboard events. No windows, no text, just a framebuffer.
Back in the day I was really happy with glut and opengl. You just took the three-line hello world and started drawing stuff without fuss. ImGui seems too unnecessarily complicated for me.
Shameless plug, but check out the Sokol libraries (there's also a header with a Dear ImGui rendering backend sitting on top of sokol_app.h and sokol_gfx.h):
https://github.com/floooh/sokol
...and here's a minimal standalone starter project for writing Dear ImGui apps in C I just created a couple of days ago:
https://github.com/floooh/cimgui-sokol-starterkit
...and here is a slightly more rich starter project that happens to use Sokol + Dear ImGui. It was made to create game tools fast in Zig.
https://github.com/prime31/zig-upaya
I love this!
I'm currently using my own shit headers, but this stuff is really appropriate. Thanks!
You can already directly draw using framebuffers etc. However, you will likely end up re-implementing widgets in any case, if your app gets more sophisticated.
About UI, it is not necessary that it should be heavy and bloated. Lazarus IDE, for instance, produces very small binaries even for fairly sophisticated UIs and it is quite fast.
> You can already directly draw using framebuffers etc.
Can I, really? How does one framebuffer in a couple of lines of C? Show me a simple program that draws a black 800x600 window.
> you will likely end up re-implementing widgets in any case, if your app gets more sophisticated.
Don't worry about that. My "app" won't get more sophisticated. I will never ever need any widgets nor drawing directives. Just give me a framebuffer and key/pointer events.
If you really want to go barebones, just mmap /dev/fb0 and do a memset 0 on the region of screen that you want black. Key/pointer events are a matter of reading files from /dev/input.
Yeahhhh!!! That's what FORTH is for!
https://donhopkins.com/home/archive/forth/cg/cg.f
Ha! But I want to open a _window_, if possible portably between linux and windows (just like glut was).
It seems to me that we are adding a lot of complexity and going backwards feature-wise.
GLUT (in the form of freeglut [1]) still exists (last commit is from February) and works on all major (desktop) operating systems. GLFW [2] is however much more wildly used these days and pretty much the spiritual successor of GLUT. ImGUI can run on top off all of them and doesn't provide the features (window/context creation, event handling) they do.
[1]
http://freeglut.sourceforge.net/
[2]
I still use freeglut and am mostly happy with it. Yet, I'm often mocked by my colleagues for that reason. I tried GLFW but I don't see the point of this library whose main raison d'être seems to be "not be freeglut" while having nearly identical features. Besides, the fact that it works with keycodes and not with letters is a bit annoying. The X server sends the key symbols but GLFW choses to ignore them, forcing the user to find them according to the current, difficult to find, keyboard configuration.
SDL may not be a couple of lines, but I'm fairly certain you could throw together a header to give a framebuffer to draw in 3-10 lines.
Dear ImGui is so easy to get working compared to other similar C++ libraries. For small dev teams using C++ that alone makes it super valuable.
I hate losing a day to figure out how to link in some crazy, clashing dependencies. Never had that problem with this library.
Over decades, I had developed an almost not-invented-here attitude exact because dependencies are always such a pita (oh Python hell) and drag in a lot of bloat. Rust is the first language I have used where external dependencies (from crates.io) Just Works(TM). However they can still drag in bloat :)
"Dear ImGui is designed to enable fast iterations and to empower programmers to create content creation tools and visualization / debug tools (as opposed to UI for the average end-user)."
I'm reminded a little of the FOX Toolkit, [0] but ImGui has more of an emphasis on accelerated graphics.
[0]
How are these similar in any way except for being GUI libraries?
> How are these similar in any way except for being GUI libraries?
They didn't say it was similar, they said imgui reminded them of it.
> You will need a backend to integrate Dear ImGui in your app. The backend passes mouse/keyboard/gamepad inputs and variety of settings to Dear ImGui, and is in charge of rendering the resulting vertices
Some people say this thing is platform agnostic, which is sort of true. But in no way does it give you a multiplatform GUI. You must provide this "backend" for every OS you want to run on. If you decide to handle that with QT, GTK, or WX, then what use is this?
If you are already using qt, gtk or wx, then dear imgui is not really aimed at you. The intended use case is more the situation where you already have what you term the backend, and you want to add a gui to your program.
(There's not much that's platform-specific in dear imgui, so you end up with a GUI that's as multiplatform as your program is.)
Game devs are probably using SDL2 or equivalent, at which point they can just use SDL2's simple cross-platform primitives to get everything they need to use Dear ImGUI.
SDL2 doesn't have the right primitives for easy dear imgui use; there's no renderer-agnostic support for drawing arbitrary textured triangle lists. So you have to get right in there and do your own drawing, which is (depending on renderer) anything from straightforward (and SDL will even give you a hand) to tiresome.
There's a longstanding sporadically-updated fork of SDL that kind of fixes this, but it's something that the SDL team don't seem to have much interest in. See
https://bugzilla.libsdl.org/show_bug.cgi?id=1734
That might be a good idea. I hadn't thought of SDL which would provide a bare minimum to get cross platform.
Here is a writeup from someone trying to get SDL to work with Dear ImGui. It kind of works, but...
https://retifrav.github.io/blog/2019/05/26/sdl-imgui/
You can feel this persons frustration about all the obscure magic incantations needed to get a simple GUI and some lines on screen. The really awful part is the last bits where he discusses how to get the damn thing compiled on Win/Linux/Mac. Even installing all the needed bits is an ordeal. Only a masochist would love this - which to be fair, probably describes game developers as a group.
The real question is why is this so hard? Or rather why does this require so much random obscure knowledge in this day and age? And all of this is so ridiculously brittle. You're one OS upgrade from the whole thing falling apart either on the build side or on the user side.
That's why people today just write HTML/JavaScript browser GUI for whatever they're doing and call it a day. It's way easier.
> You can feel this persons frustration about all the obscure magic incantations needed to get a simple GUI and some lines on screen.
The vast majority is setting up SDL with a graphics context - anything graphics in C++ land is notoriously tedious, yes - not much of that is in control of Dear ImGui.
If you look at "Plugging Dear ImGui into SDL" there's a total of 14 lines involved in adding Dear ImGui over an existing SDL+OpenGL application, which is the precise target use of Dear Imgui.
Here are the lines:
// Init
IMGUI_CHECKVERSION();
ImGui::CreateContext();
ImGui::StyleColorsDark();
ImGui_ImplSDL2_InitForOpenGL(window, gl_context);
ImGui_ImplOpenGL3_Init(glsl_version.c_str());
// Event forwarding
ImGui_ImplSDL2_ProcessEvent(&event);
// New frame
ImGui_ImplOpenGL3_NewFrame();
ImGui_ImplSDL2_NewFrame(window);
ImGui::NewFrame();
// Rendering
ImGui::Render();
ImGui_ImplOpenGL3_RenderDrawData(ImGui::GetDrawData());
// Shutdown
ImGui_ImplOpenGL3_Shutdown();
ImGui_ImplSDL2_Shutdown();
ImGui::DestroyContext();
Everything else is setup that has nothing to do with dear imgui, or excess dear imgui usage demo from that article.
I'm not sure it's possible to make it any easier other that adding a wrapper across all back-ends.
Yes, setting up graphics stuff in C++ is not trivial, but that's not Dear ImGui fault.
> Only a masochist would love this - which to be fair, probably describes game developers as a group.
Yes. Game developers are people who can have GTA5 running on a PS3, a console with 256x2 MB of RAM, while web applications displaying a chat frequently use more memory than that. I guess you call it masochist, I call it being efficient and excellent.
https://www.youtube.com/watch?v=d0KJhFMnWRI
I'm curious on what opinions are on Dear ImGui's bindings in other languages, namely Rust. imgui-rs seems to be one of the only mature-ish GUI libraries, but I found myself struggling with it. The multiple window "debug view" looks great, but for something like an OpenGL window with a simple menu bar, I found it difficult to create. There is also apparently no file picker widget, which I found to be a big downside.
I don't work that much with GUI applications, but Dear ImGui was perfect for a past project and I just wanted to chime in on the positive feedback :) Take care everyone!
For those who may be unfamiliar with the "immediate mode" vs "retained mode" terminology here, an aha moment for me was realizing frameworks like React are essentially immediate mode APIs (such as declarative JSX) abstracting an underlying retained-mode system (the DOM).
It may not be a perfect analogy, but seems to be basically true.
Qt seems to be the most popular library for cross-platform GUI apps written in C++. Is Dear ImGui a credible alternative?
How does Dear ImGui compare to Qt?
They are very different in terms of usage. Dear ImGui is an immediate mode UI library which means that rendering and evaluation happen at the same time. You write for example:
_if (ImGui::Button("X")) { //pressed handler }_
This renders the button and handles its state at the same time.
Qt is a more traditional callback based UI although with their own signal/slot system which has nice features like thread safety built in. I last used Qt a while ago though so maybe it works different nowadays.
Qt is a full-fledged application framework with a retained mode GUI being just a part of it. Dear ImGui is a specialized immediate mode GUI library (hence the name).
Depends on what you want to use it for.
Qt is essentially a full-blown operating system wrapper, Dear ImGui is much more focused on creating UIs quickly and has a different background (coming out of the gamedev world for creating inhouse-tools and debugging UIs integrated into games). It's just around 25kloc of code, has no external dependencies, compiles to a few dozen KBytes and is very easy to integrate into an existing code base.
Well, these are as different as it gets. Dear ImGui is purely code based and it's drawing in immediate mode. Meaning there is no way to have a visual tool to arrange layouts for things, you have to do everything in code. It's fantastic for debugging, prototyping, very simple interfaces when that's all that's required, but it's not a fully fledged UI library like QT. It's like comparing a bicycle to a 4x4. Sure a bicycle works better in some uses cases, but for it's not designed for heavy lifting.
ImGui is not drawing in immediate mode (which isn't supported any more in any contemporary accelerated graphics API). Only the API is immediate mode. You can Begin() the same window multiple times and each time you do it during a frame you keep appending to the same window.
This point is so important that it bears repeating: only the _programming model_ is "immediate", not the implementation under the hood.
Dear ImGui keeps (internal) state around between frames, maybe not as much as other UI frameworks, but it does. Especially the rendering isn't "immediate mode", the UI isn't rendered while running the code that's building the API. Instead Dear ImGui builds a "deferred mode" rendering command list which is actually very efficient in terms of required draw calls.
The main difference to traditional UI frameworks is that there are no different code paths for UI creation, UI updating, and handling input. Instead all those things are happening in the same sequential code flow.
Rather important is the state ImGui keeps around is independent of the number of widgets. (Imgui's inter-frame state is essentially a list of top-level windows, a list of pressed buttons and the ID of the active/focused widget -- that's enough). This makes ImGui perfect for inserting it into the traversal of complex data structures and ensures perfect synchrony between UI and data. This is an area were classic GUI tooling often struggles; sure it's totally possible to do with e.g. Qt but making a scene graph accessible as a Qt model likely amounts to a few thousand lines of code, but is comparatively trivial with tightly-coupled ImGui code. Embedding GUIs into a 3D viewport is also something these frameworks aren't generally designed to do, but is the easiest way to do it with ImGui.
That being said, real GUI frameworks like Qt are a much better choice for 97 % of "end-user tools", because they have all the bells and whistles you do, in fact, want to have in a desktop application (RAD tools, proper layout system, proper menu/action system, accessibility integration, state inspection etc.)
> ... because they have all the bells and whistles...
None of that is incompatible with the immediate-mode-UI philosophy though, it's just that this specific UI toolkit (Dear ImGui) is coming from a direction where those things haven't been that important.
Oh but it is. A proper menu/action system requires the toolkit to retain all menus and actions; ImGui doesn't do that (and shouldn't, considering all the places you can put a menu), it also requires layered event handling, which ImGui doesn't want to have. Accessibility requires a retained widget tree, which ImGui explicitly doesn't want. Layouts are incompatible with the current immediate mode API (but could be implemented in an immediate mode API given a legion of lambdas), because the size of widgets depends on the size and possibly contents of other widgets; for ImGui this is all fixed when you call Button(), which immediately calculates all vertices and adds them to the drawlist (that's the retained part in ImGui). There are probably many more points.
I still see those mostly as implementation details of this specific library (Dear ImGui), not as problems of the general idea of UIs that are described through an immediate mode API. I'm sure I'm missing a few important details, but what's preventing another library to make the internals more retained while keeping the illusion of an immediate mode UI on the user side of the API (which is the important part).
The internal implementation may be much more complicated than what Dear ImGui does, maybe it's necessary to run multiple passes over the UI description to create the layout, etc... but that might be worth it if the programming model remains as simple as it is now.
Well yes, sorry, I misspoke.
I'm not disagreeing with you that Dear ImGUI is not at the same level as Qt for an end-user app but if you want to make a visual tool for creating UIs in ImGUI there is nothing stopping you. You write some tool to walk over your description of the data and call the correct functions. Nothing hard or special about it.
No. It's super easy to get going with IMGUI which is what so many solo developers love. I want to make my thing, not learn a new framework. The problem is it won't take you all the way to a polished user-facing GUI without you having to re-write a bunch of it.
Dear ImGui is amazing software with great ideas, but at this point I feel like the "immediate" is a problematic lie much like how "immediate mode" graphics rendering hasn't been immediate in years. I think the most appropriate way to describe these libraries is "imperative", because you're constructing retained state by running imperative code and the library is responsible for figuring out how to do what you want it to do.
Any properly functioning UI with the features needed by more than a handful of users ends up having to retain a considerable amount of state. This doesn't mean that you need to construct a huge graph of interconnected object goo, but a bunch of C/C++ calling functions every frame with no retained state won't cut it. Libraries like Dear ImGui and Nuklear largely solve this with a combination of wasted energy (by running your code repeatedly) and magical hidden state (managing retained state in the background for you automatically).
The fact that retained state does end up existing but behind the curtain means that annoying problems manifest themselves due to it being out of your control. For example, a textbox needs to maintain the current selection along with a scroll offset in its viewport, along with an undo/redo history. You might decide to drop some of that but some of it has to stick. In Nuklear's case, it relies on stb_textedit to do a lot of the heavy lifting (great library!) and retains state for you behind the scenes. Because the state management is automatic based on the small amount of information Nuklear has, doing something like collapsing a hideable panel makes the textbox "disappear" at which point the scroll offset, selection and undo/redo history vanish. The user may have accidentally collapsed the panel (or the program did it for them), and you've now responded to that input by throwing away something very important. You certainly _could_ retain all this state inside your application (whether or not there's an API for it in the library is another question), but now you have to come up with a solution for tracking and storing all that state.
Other comments have already mentioned the "page tearing" problem (needing an extra frame to respond to state changes, etc) which is one manifestation of this fundamental issue - that retained state is in fact necessary and hiding it creates new problems - but there are other challenges that are easier to ignore. Accessibility is a major one, and current IMGUI libraries are entirely ill-prepared to address it. Another issue is internationalization - not only is RTL text an issue, but complex character sets require shaping (an expensive operation) which also requires caching and additional infrastructure that is going to clash painfully with the very simple "just draw some text" model used by most of these libraries. International text input is also very stateful and you'll find that interacting with IMEs is quite difficult if you aren't careful about things. (This is especially bad because SDL2 itself has a botched IME implementation, so users of non-western character sets are screwed right out of the gate.)
I've been using Nuklear over the past couple years for some development tools and the experience soured me on IMGUI libraries in general because I kept running into these problems that, in retrospect, should not have been a surprise. The UI had lots of rough edges you'd feel when using it, it was ugly (until I aggressively patched it to address this), it was slow, etc. Dear ImGui is likely higher quality than Nuklear (not that I can say for sure, because I never got it to work due to integration problems) but the fundamental design principles are largely the same and it has its own set of limitations. I'm hopeful that as time passes these libraries will continue to improve, but I've personally moved on to accepting that a good UI needs retained state and I'm focusing on ways to make constructing that state as easy as possible without leaving users who need accessibility or foreign character sets out in the cold.
Some less relevant footnotes:
Visually it doesn't look so good out of the box. Are there some extra styles or libraries etc out there which implement good looking styles on top of Dear ImGui? Or are dev expected to put their own style on top of it?
Usually it's used for debug interface in game engines, it's not really meant for full-fledged applications (although you could use it for that usecase).
It looks good compared to the hand-rolled debug GUIs that game developers often implement themselves on top of OpenGL. But, yeah.
Dear ImGui – Bloat-free graphical user interface library for a bloated programming lanugage
FTFY
Is there usable _Dear ImGui_ fork/sample for _OpenGL 1.x_?
All Dear ImGUI does is generate arrays of vertices + texture coordinates. That's it. It doesn't support any particular graphics API. There are examples in the repo but they are just that, examples.
If you want to use it in OpenGL 1.0 it shouldn't take you more than a few minutes.
It definitely does come with backends for various APIs:
https://github.com/ocornut/imgui/tree/master/backends
Those are examples. They are not Dear ImGUI. Dear ImGUI is 2 files, that's it. The rest is just examples of how to integrate it. If you can't figure out hot to draw a list of vertices with texture coordinates in any API then you probably aren't the target for Dear ImGUI
> _It definitely does come with backends for various APIs:_
And there are NO _imgui_impl_opengl1.cpp_ & _imgui_impl_opengl1.h_, only next:
...
imgui_impl_opengl2.cpp
imgui_impl_opengl2.h
imgui_impl_opengl3.cpp
imgui_impl_opengl3.h
...
UPD: Some say[0] that _imgui_impl_opengl2.cpp_ really is _imgui_impl_opengl1.cpp_:
> _imgui_impl_opengl2.cpp is actually misnamed and should be imgui_impl_opengl1.cpp._
[0]
https://discourse.dearimgui.org/t/missing-glactivetexture-ca...
It's definitely possible but I guess nobody has done it yet because the usual GL "baseline" version these days is GLES2 (and that mostly because of WebGL). Each rendering command you get back from Dear ImGui comes with a block of vertices and indices. Typically those are stashed into 3D-API vertex- and index-buffers for efficient rendering, but they can just as well be "unrolled" to glBegin/End calls, it's just not as efficient. With a good GL driver this probably doesn't matter much though.
Putting the "immediate" back in "ImGui".
Does it support GPUs and Wayland directly?
ImGui itself doesn't have its own renderer, it just provides a list of simple rendering commands which then must be rendered by your own code (the git repo comes with ready-to-use example renderers using any of the standard 3D-APIs, GL, D3D, Metal, Vulkan, etc...). That way it's easy to integrate into existing code bases and portable to all sorts of "exotic" platforms (for instance game consoles - which generally don't have "standard" APIs).
until accessibility is implemented, don’t use this please
Until you understand the objective of the project, don't comment please
I think ZenPsycho is right calling out for accessibility features. It's unfortunate that most low-key UI libraries don't support them, partly because those OS API are so complex and for a non-user it is hard to understand them (much like for English users it is sometimes hard to understand what's needed for localization).
A pragmatic way to see it - and arguably it's an issue I don't have answer for - is that the sum of all desirable modern features (incl. but not limited to accessibility features) are growing the scope so complex and large it is also - very unfortunately - hindering innovation. Everyone agrees accessibility features are desirable. Yet if every experimental or hobbyist project needed to implement all accessibility features, those projects wouldn't exist. So two steps forward is costing us one step back here :(. There are _so many things_ dear imgui doesn't do at this point, it can't handle full internationalization and right-to-left text. Maybe it'll catch up. Maybe other solutions will solve this. For now as I don't have the resources to do it all myself. But the more people use and work with a given software the more likely it is to evolve and improve. I would gladly surrender to a much better product than dear imgui that implemented this while also solving the problems dear imgui aims to solve.
This is a library for building internal tools, debug GUIs etc. This is not Qt/GTK, or React, or a CSS framework.
Any internal tool or debug GUI has reasonable odds of becoming a user-facing tool eventually, and it's a matter of time until you end up needing to support staff/customers in territories with RTL languages or ideographic character sets. At that point, you end up regretting most of the corners you cut.
I built lots of internal developer tools for a mid-sized western studio and it wasn't long until I had to go back and patch in a bunch of localization support because it turned out the publishers overseas needed to be able to use it and not all of their staff spoke English. Any blind employees were probably completely out of luck (maybe not, I did use Win32.)
Please watch this -
https://www.youtube.com/watch?v=94swlF55tVc
Where do you draw the line? Some companies are using it for polished large tooling which may have thousands of end-users. Those users will eventually want a solution to tackle that.
Until HR/regulations/compassion hits you, please don't comment please.
Got it though - these things are perceived as - meh, why would I need it - I have perfect vision, two hands, can speak, can hear, can touch, etc. And then you start realizing you maybe working with folks with disabilities, and the same products/apps that you are working with allow them to do so (like Visual Studio), so on one hand it's easy to ignore them (without even realizing so), but once you've become aware of what they are facing, and seen enough it makes you think - should I use this, because there is no native control, and usually native controls have ways to be decoded by Assistive tech (my reasons back in the days to prefer wxWidgets over Qt), or recently even if it's non-native (Qt, flutter, etc) it can feed to the assistive sdk (say on Windows) details of what's going on in the control.
It's rather important! It's not just a gimmick. It shows compassion, love, and someone might already a project doing so with "Dear IMGUI" (not aware of one), but probably internals can be exposed in some fashion.
Is this truly what you want? We're developers, I'd think a call out to help bring in a11y would be better recieved.
The problem is that accessibility APIs are very limited and stagnated in every single OS (except maybe Apple).
For basic default widgets accessibility works out-of-the-box, but as soon as you want to do something more complex or do custom drawing like Dear ImGui does, you're forced to write WAY more code than anticipated.
In Windows, for example, you need significantly more code to get a11y than to draw a custom widget. If you're drawing to a framebuffer like Dear ImGui is doing, it's even worse. In some OSs have to use other APIs (like focus management) to take advantage of the a11y APIs, which is kind of "at odds" with the whole immediate-GUI paradigm.
This is amazing new for corporation-backed products like Flutter, React Native or even Qt, because it makes the barriers to entry way higher. On the other hand, open source project will lack the resources to do proper native a11y.
Asking OS vendors to have proper accessibility in their OSs is IMO the more appropriate step for accessibility advocates, rather than forcing dozens of Open Source projects to reimplement the same thing over and over.
> Asking OS vendors to have proper accessibility in their OSs is IMO the more appropriate step for accessibility advocates
What more should OS vendors do? Is there anything OS vendors could do that would actually help the state of accessibility in fringe GUI toolkits like Dear ImGui? This isn't a rhetorical question. In addition to being an outspoken accessibility advocate on threads like this one, I'm currently a developer on the Windows accessibility team at Microsoft, which owns the UI Automation API among other things, and I want to know what more we should be doing.
Hello Matt,
For a small developer I believe the whole topic seems quite overwhelming. To attract fringe GUI toolkits it would be useful to provide easy-to-chew accessibility samples based over 3d graphics technology (say: take a DirectX11 samples drawing a few text and buttons and make it accessibility compliant).
That's a fair request. All of the full-featured accessibility implementations are buried in complex UI frameworks and browser engines. I'm also aware that the sample UIA provider implementations in the Windows SDK aren't very useful; they all implement a single control in its own HWND, using GDI or GDI+.
As part of Microsoft's Hack for Good program, I worked with the developers of the Quorum language and development environment (
) on their UIA implementation. So I know how frustrating it can be for a non-expert to implement UIA, and how easy it is to get it wrong.
I'll have to see what I can do about implementing a better sample.
Just better documentation, tutorials and samples would improve the situation 100x! The current ones are hard even for veteran native programmers.
Next thing I'd love to see would be a simplified API to allow smaller developers to also use it. As it is, only giant companies can afford handling accessibility.
A personal wish would be to have an immediate mode imperative API for accessibility that abstracts the Automation Tree. Similar to how Dear ImGui does. Something like: BeginFrame, TextInput, Checkbox, EndFrame, etc... plus some commands to "ask" if the Automation API wants to do something, like moving to the next control. Maybe a Dear ImAccessibility?
This would work perfectly for Video Games and would allow accessibility to added even to games that didn't predict it. Games are pretty simple, and don't require too much variety. I worked in an Adventure Game in the past and it would be 100% playable using A11y with something like that. I would love to make a 100% accessible game in the future.
This of course could be a simple multi-platform wrapper instead of something from your team.
This would also drastically improve the accessibility situation for games!
The widget should keep its state private.
ImGui::InputText("string", buf, IM_ARRAYSIZE(buf));
ImGui::SliderFloat("float", &f, 0.0f, 1.0f);
And maybe is a C++ lib but the interface is C with namespaces. Odd.
Immediate mode is a stateless design pattern.
The way I understand it, the idea is that widgets don't own the state. They are sort of stateless. Your app owns the state.
Exactly, the app owning (most of) the state is precisely the point of ImGui.
Public interface with C makes sense. C++ doesn't have portable ABI plus it makes porting harder.