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

91–100 of 186 posts

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

#91

Post by milansuk »

pkphilip wrote: post #80
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…

Have you considered developing using an IDE like Lazarus but with extensions allowing the component library to use Imgui instead of the default Lararus components? https://www.lazarus-ide.org/

I heard about Lazarus, but never tried it. I'll give it a shot.

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

#92

Post by JabavuAdams »

DethNinja wrote: post #88
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…

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?

Dragging around a pointer, or scrubbing a line will be noticeably laggy with > 0 frame delay. It leads to a sluggish feeling that may be okay in the web world, but is kind of against the whole aesthetic of performant native apps. What's strange to me is that Muratori is a huge stickler for performance, like Jon Blow. I can't imagine him being happy with any kind of lag.

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

#93

Post by robinei »

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 immediate mode interface, not about layout/rendering/input handling happening at the same time as view functions are called. And don't do "if (Button()) { ... }", but use lambdas for event handling, so the handlers can be invoked at the proper time when everything is laid out.

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

#94

Post by flohofwoe »

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.

Anectodal etc etc, but when I started using Dear ImGui a few years ago I had no idea about the origins of immediate mode UI, or what "immediate mode UI" even means, and neither had heard of Casey Muratori nor Omar Cornut.

All I saw was a very enjoyable way to create UIs, something I loathed before (like most other programmers I guess). So far I haven't come across another UI toolkit which is as enjoyable to use as Dear ImGui (and that includes a couple of other ImGui libraries), and that's the reason why I stick to it, not because of some sort of cult of personality ;)

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

#95

Post by enriquto »

pkphilip wrote: post #86
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.

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 framebuffer and key/pointer events.

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

#96

Post by varispeed »

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 when you try to instatiate such window then the other window goes crazy or if you close the modal window everything closes and there would be no way to fix it other than digging into library code. I hope this one is not like that.

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

#97

Post by CountHackulus »

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…

That looks more like coupling the state with the UI. You could try refactoring your code in an MVC/MVVM style like react such that the state isn't being modified during a UI draw. That sort of out-of-sync issue can happen even with retained mode UIs. I wouldn't say it's fundamental to the paradigm that you intersperse your business logic into your UI. Granted at large scales basically any UI framework falls apart.

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

#98

Post by softawre »

varispeed wrote: post #96

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…

Did you read far enough in the readme to see the screenshots of the projects using this already? Those look like very complex UIs, and at least one of them is open source for you to look at.

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

#99

Post by MattRix »

varispeed wrote: post #96

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…

Dear ImGui is not some half-baked experiment. It's used in tons of real world projects right now. The main way I've seen it used is for developer-facing GUI (debug views, tool/editors, etc)

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

#100

Post by ocornut »

mwcampbell wrote: post #85
ratww wrote: post #71

Earlier quoted context omitted.

The problem is that accessibility APIs are very limited and stagnated in every single OS (except maybe Apple). For basic default widgets accessibility works out-of-the-box, but as soon as you want to do something more complex or do custom drawing like Dear ImGui does, you're forced to write WAY more code than anticipated. In Windows, for example, you need significantly more code to get a11y than to draw a custom widg…

> Asking OS vendors to have proper accessibility in their OSs is IMO the more appropriate step for accessibility advocates What more should OS vendors do? Is there anything OS vendors could do that would actually help the state of accessibility in fringe GUI toolkits like Dear ImGui? This isn't a rhetorical question. In addition to being an outspoken accessibility advocate on threads like this one, I'm currently a de…

Hello Matt,

For a small developer I believe the whole topic seems quite overwhelming. To attract fringe GUI toolkits it would be useful to provide easy-to-chew accessibility samples based over 3d graphics technology (say: take a DirectX11 samples drawing a few text and buttons and make it accessibility compliant).

Post reply on HN