Live data from Hacker News

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

github.com

121–130 of 186 posts

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

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

Videocards redraw every frame anyway.

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

#122
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…

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.

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

#123
post #72
post #66

Earlier quoted context omitted.

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

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…

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.

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

#124
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’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.

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

#125

I'm reminded a little of the FOX Toolkit, [0] but ImGui has more of an emphasis on accelerated graphics. [0] http://fox-toolkit.org/

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.

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

#126

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

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!

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

#127

Earlier quoted context omitted.

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

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.

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

#128
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…

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.

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"

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

#129
post #123
post #72

Earlier quoted context omitted.

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…

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.

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

#130

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…

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

Post reply on HN