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

61–70 of 186 posts

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

#61

Post by Torkel »

greggman3 wrote: post #43
Torkel wrote: post #13

Earlier quoted context omitted.

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.

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

#62

Post by exDM69 »

milansuk wrote: post #58
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…

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

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.

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

#63

Post by tgb »

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…

Can you explain what "page tearing" is?

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

#64

Post by enriquto »

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.

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

#65

Post by flohofwoe »

formerly_proven wrote: post #55
flohofwoe wrote: post #49

Earlier quoted context omitted.

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

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.

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

#66

Post by dthul »

tgb wrote: post #63
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…

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.

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

#67

Post by dgr582systems »

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.

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

#68

Post by flohofwoe »

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

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

#69

Post by enriquto »

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

I love this!

I'm currently using my own shit headers, but this stuff is really appropriate. Thanks!

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

#70

Post by milansuk »

exDM69 wrote: post #62
milansuk wrote: post #58

Earlier quoted context omitted.

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

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

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.

Post reply on HN