Dear ImGui – Bloat-free graphical user interface library for C++ • Hacker News Board

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

#161

Post by malkia » Wed, Nov 04, 2020, 9:07 PM UTC

mholub wrote: post #51

roytries wrote: post #7

Not sure why this is showing up on HN today. But Dear ImGui is absolutely amazing. And its not just for C++. I use it myself in my C# game engine. (There's a C# port that uses System.Numerics: https://github.com/mellinoe/ImGui.NET ) which I've ported to MonoGame https://github.com/roy-t/ImGui.NET ) I've used a lot of different UI frameworks (winforms, WPF, Html/CSS based frameworks, custom game engine frameworks). Bu…

We recently started to use Dear ImGUI in our custom game engine. Before we used Unity which has its own immediate mode gui solution. And I have hard time to switch. I don't know if I don't understand how Dear ImGui work yet in comparison to Unity's one but it feels so limited. So main difference is that Unity is multipass (it calls your gui drawing code multiple times per frame) and because of it it supports horizont…

Talk to occornut! He even posts here. Surely you gonna get some reasonable reply, or at least something. Also consider supporting him! Raise an issue on github, or look for similar before hand. I'm also torn when comes to dear imgui, but keep reading updates on it, and trying it at least few times a month with small things.

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

#162

Post by malkia » Wed, Nov 04, 2020, 9:13 PM UTC

robinei wrote: post #93

JabavuAdams wrote: post #82

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…

This is the definite TLDR on how layout/constraints in flutter works - https://flutter.dev/docs/development/ui/layout/constraints

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

#163

Post by malkia » Wed, Nov 04, 2020, 9:19 PM UTC

forrestthewoods wrote: post #124

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.

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.

Games also require said GPU computing power. Lots of UI may have to conserve power/energy - think about some IoT device that may not even have GPU, and need to use as little as possible energy.

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

#164

Post by malkia » Wed, Nov 04, 2020, 9:22 PM UTC

JabavuAdams wrote: post #90

flohofwoe wrote: post #89

Earlier quoted context omitted.

There are a lot of hidden traps when rendering anything on modern operating systems that add small latencies and those small latencies add up quickly (it was much easier on old 8- and 16-bit computers). For instance rendering something that "sticks" to the system mouse pointer and doesn't lag a few pixels behind when moving the mouse is surprisingly hard if you're rendering through a 3D API (compared to going through…

I think if it as Casey Muratori's "brain fart" that made sense in his context but that other developers have latched on to because of his influence in indie game circles. I have massive respect for him, and followed everything he did back in the late '90s and early aughts, but he's quite opinionated and has some peculiar code aesthetics / trade-offs.

I first got introduced to the concept by his talk, and this implementation here - http://sol.gfxile.net/imgui/ch01.html (latest archive I could find - https://web.archive.org/web/20200428143845/http://sol.gfxile...)

I've did some translations of the above C/C++ code to lua longtime here (actually luajit, as it requires the FFI) - https://github.com/malkia/ufo/blob/master/samples/SDL/imgui/... (simplest example) through https://github.com/malkia/ufo/blob/master/samples/SDL/imgui/... though my hack for C/C++'s __LINE__ macro was

local function GEN_ID() return CURRENT_LINE() end

e.g. you basically tie the state to the... ahem.. source code line (you need really something unique). Obviously Dear ImGUI has better approaches there (use the widget's contents, like text/label contents, or add your own with ##).

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

#165

Post by malkia » Wed, Nov 04, 2020, 9:24 PM UTC

prvc wrote: post #9

>This library is called Dear ImGui. Please refer to it as Dear ImGui (not ImGui, not IMGUI). >(The library misleadingly started its life in 2014 as "ImGui" due to the fact that I didn't give it a proper name when when I released 1.0, and had no particular expectation that it would take off. However, the term IMGUI (immediate-mode graphical user interface) was coined before and is being used in variety of other situat…

I actually love that - it's very personal, fun, loving, something that you've endured and made it happen. Simply love the naming. Just "imgui" is not going to make it, although "imgui" now is mostly associated with exactly "Dear ImGUI".

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

#166

Post by corysama » Wed, Nov 04, 2020, 9:35 PM UTC

ocornut wrote: post #137

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.

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.

This is a very common problem on modern machines and modern software. Engineers default to putting in so much machination of caches and dirty-flags to avoid redundant processing that they end up making something that does way more work to avoid work than a decent implementation of just blindly doing the work all-gas-no-brakes.

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

#167

Post by malkia » Wed, Nov 04, 2020, 9:38 PM UTC

mcdevilkiller wrote: post #37

ZenPsycho wrote: post #2

until accessibility is implemented, don’t use this please

Until you understand the objective of the project, don't comment please

Until HR/regulations/compassion hits you, please don't comment please.

Got it though - these things are perceived as - meh, why would I need it - I have perfect vision, two hands, can speak, can hear, can touch, etc. And then you start realizing you maybe working with folks with disabilities, and the same products/apps that you are working with allow them to do so (like Visual Studio), so on one hand it's easy to ignore them (without even realizing so), but once you've become aware of what they are facing, and seen enough it makes you think - should I use this, because there is no native control, and usually native controls have ways to be decoded by Assistive tech (my reasons back in the days to prefer wxWidgets over Qt), or recently even if it's non-native (Qt, flutter, etc) it can feed to the assistive sdk (say on Windows) details of what's going on in the control.

It's rather important! It's not just a gimmick. It shows compassion, love, and someone might already a project doing so with "Dear IMGUI" (not aware of one), but probably internals can be exposed in some fashion.

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

#168

Post by moonchild » Wed, Nov 04, 2020, 9:39 PM UTC

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.

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 implementations will cache the scene graph+layout anyway, and only rebuild the parts they need to. Which is slightly more CPU-intensive, but not appreciably so.

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

#169

Post by malkia » Wed, Nov 04, 2020, 9:41 PM UTC

mcdevilkiller wrote: post #139

ocornut wrote: post #59

Earlier quoted context omitted.

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.

Please watch this - https://www.youtube.com/watch?v=94swlF55tVc

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

#170

Post by forrestthewoods » Wed, Nov 04, 2020, 9:47 PM UTC

malkia wrote: post #163

forrestthewoods wrote: post #124

Earlier quoted context omitted.

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.

Games also require said GPU computing power. Lots of UI may have to conserve power/energy - think about some IoT device that may not even have GPU, and need to use as little as possible energy.

Or smartphones where you want to conserve battery life.

I think people dramatically overestimate the cost to perform simple UI layout. There’s no reason that CPU time should be more than 1ms single-thread for most apps. GPU time should be similarly small. Modern smartphone supercomputers are FAST!