Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear ImGui – Bloat-free graphical user interface library for C++

github.com

Post reply on HN
Print view View original

41–50 of 186 posts

Re: Dear ImGui – Bloat-free graphical user interface library for C++

#41

Post by formerly_proven »

flohofwoe wrote: post #40
formerly_proven wrote: post #32

Earlier quoted context omitted.

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 c…

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.)

Re: Dear ImGui – Bloat-free graphical user interface library for C++

#43

Post by greggman3 »

Torkel wrote: post #13
gambiting wrote: post #10

Earlier quoted context omitted.

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.

Re: Dear ImGui – Bloat-free graphical user interface library for C++

#44

Post by flohofwoe »

exDM69 wrote: post #39

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…

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.

Re: Dear ImGui – Bloat-free graphical user interface library for C++

#45

Post by greggman3 »

gambiting wrote: post #17
pansa2 wrote: post #14

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?

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 bicy…

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.

Re: Dear ImGui – Bloat-free graphical user interface library for C++

#46

Post by formerly_proven »

exDM69 wrote: post #39

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…

> 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).

Re: Dear ImGui – Bloat-free graphical user interface library for C++

#47

Post by greggman3 »

app4soft wrote: post #29

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.

Re: Dear ImGui – Bloat-free graphical user interface library for C++

#48

Post by flohofwoe »

andybak wrote: post #42

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... :)

Re: Dear ImGui – Bloat-free graphical user interface library for C++

#49

Post by flohofwoe »

formerly_proven wrote: post #41
flohofwoe wrote: post #40

Earlier quoted context omitted.

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 c…

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 to…

> ... 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.

Re: Dear ImGui – Bloat-free graphical user interface library for C++

#50

Post by hartmel »

- 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.

Post reply on HN