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

171–180 of 186 posts

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

#171

Post by b20000 »

userbinator wrote: post #103
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…

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.

i plan using it in a data viz app. works great! much better experience than traditional GUI toolkits.

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

#172

Post by Torkel »

woodrowbarlow wrote: post #147
Torkel wrote: post #61

Earlier quoted context omitted.

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

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?

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

#173

Post by app4soft »

account42 wrote: post #114
greggman3 wrote: post #47

Earlier quoted context omitted.

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

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

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

#174

Post by t0astbread »

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…

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.

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

#175

Post by prime31 »

flohofwoe wrote: post #68
enriquto wrote: post #64

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

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

#176

Post by Torkel »

DonHopkins wrote: post #129
ska wrote: post #123

Earlier quoted context omitted.

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

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

#177

Post by tom_ »

kevingadd wrote: post #144
phkahler wrote: post #109

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

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

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

#178

Post by FullyFunctional »

dgr582systems wrote: post #67

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

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

#179

Post by exDM69 »

moonchild wrote: post #168
userbinator wrote: post #103

Earlier quoted context omitted.

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.

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

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

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

#180

Post by Cloudef »

dasloop wrote: post #4

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.

Public interface with C makes sense. C++ doesn't have portable ABI plus it makes porting harder.
Post reply on HN