Live data from Hacker News

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

github.com

131–140 of 186 posts

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

#131

Earlier quoted context omitted.

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

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

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

#132

Earlier quoted context omitted.

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"

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.

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

#133

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…

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?

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.

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

#134
post #93

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…

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

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.

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

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

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.

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

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

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.

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

#138

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…

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

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

#139
post #59

Earlier quoted context omitted.

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…

This is a library for building internal tools, debug GUIs etc. This is not Qt/GTK, or React, or a CSS framework.

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

#140

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.

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.
Post reply on HN