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

71–80 of 186 posts

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

#71

Post by ratww »

minerjoe wrote: post #34
ZenPsycho wrote: post #2

until accessibility is implemented, don’t use this please

Is this truly what you want? We're developers, I'd think a call out to help bring in a11y would be better recieved.

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 widget. If you're drawing to a framebuffer like Dear ImGui is doing, it's even worse. In some OSs have to use other APIs (like focus management) to take advantage of the a11y APIs, which is kind of "at odds" with the whole immediate-GUI paradigm.

This is amazing new for corporation-backed products like Flutter, React Native or even Qt, because it makes the barriers to entry way higher. On the other hand, open source project will lack the resources to do proper native a11y.

Asking OS vendors to have proper accessibility in their OSs is IMO the more appropriate step for accessibility advocates, rather than forcing dozens of Open Source projects to reimplement the same thing over and over.

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

#72

Post by Torkel »

dthul wrote: post #66
tgb wrote: post #63

Earlier quoted context omitted.

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 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 adds to a list.

There is no problem in redrawing everything from state every frame. There is no problems in having "half frame be old state" - even at 30 fps it is not noticeable.

We use a separate update() and gui() path though. So all entities will get an update opportunity even if the gui is hidden. And state is kept in a config that is beautiful to use... Maybe the issues here comes from not having those parts.

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

#73

Post by boomlinde »

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…

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

Suppose that the widget functions apply one of two different strategies depending on the call context: 1. Render the widgets and 2. Evaluate the layout and process input accordingly. You invoke the GUI code in the second context on every input, and after that invoke it in the first context only if the calls in the second context potentially resulted in a change. This minimizes re-rendering and eliminates page tearing while allowing you to re-render reactively to events.

You will of course still need some kind of basic state tracking to make the GUI re-render to reflect changes that are not triggered by input.

In general, I agree, though. The right tool for the right job.

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

#74

Post by [deleted] »

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…

[deleted]

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

#75

Post by ratww »

flohofwoe wrote: post #44
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…

Wouldn't it be possible to separate the public API from the internal implementation so much that the library appears "immediate mode" on the outside, but is completely "retained mode" on the inside? With a persistent widget tree which is only manipulated by diffing it against the current frame's UI description provided by the user code? The important feature of immediate mode UIs is that there's only one sequential p…

> Wouldn't it be possible to separate the public API from the internal implementation so much that the library appears "immediate mode" on the outside, but is completely "retained mode" on the inside?

It is possible but you would need some severe API changes... you could either ask the users to use unique names for each widget, or something similar like storing references between frames. Alternatively you'd have to force "same order between frames" (similar to React does with Hooks).

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

#76

Post by flohofwoe »

ratww wrote: post #75
flohofwoe wrote: post #44

Earlier quoted context omitted.

Wouldn't it be possible to separate the public API from the internal implementation so much that the library appears "immediate mode" on the outside, but is completely "retained mode" on the inside? With a persistent widget tree which is only manipulated by diffing it against the current frame's UI description provided by the user code? The important feature of immediate mode UIs is that there's only one sequential p…

> Wouldn't it be possible to separate the public API from the internal implementation so much that the library appears "immediate mode" on the outside, but is completely "retained mode" on the inside? It is possible but you would need some severe API changes... you could either ask the users to use unique names for each widget, or something similar like storing references between frames. Alternatively you'd have to f…

Dear ImGui already uses such "implicit" widget ids, by default it hashes the widget's label string, window title or name, with a convention to add an invisible 'identifier string' to the label string separated by a "##" (e.g. "Label##id") - for the case that the visible label string needs to change or isn't unique within the current scope. There are also separate PushID/PopID functions to manage such widget ids in "more elaborate ways".

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

#77

Post by prvc »

reyqn wrote: post #31
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 would guess, since it has been rebranded on christmas day, that it's named Dear ImGui because when you would write a letter to Santa Claus, you would start by "Dear Santa" (or at least in french, "Cher père Noël"). Maybe a parallel is to be made between the library and Santa Claus, because if you ask for something kindly, you would magically have it, without it being cumbersome for you.

In fact, this is conventional for letters in general-- not only to Santa, and not only in French.

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

#78

Post by ratww »

flohofwoe wrote: post #76
ratww wrote: post #75

Earlier quoted context omitted.

> Wouldn't it be possible to separate the public API from the internal implementation so much that the library appears "immediate mode" on the outside, but is completely "retained mode" on the inside? It is possible but you would need some severe API changes... you could either ask the users to use unique names for each widget, or something similar like storing references between frames. Alternatively you'd have to f…

Dear ImGui already uses such "implicit" widget ids, by default it hashes the widget's label string, window title or name, with a convention to add an invisible 'identifier string' to the label string separated by a "##" (e.g. "Label##id") - for the case that the visible label string needs to change or isn't unique within the current scope. There are also separate PushID/PopID functions to manage such widget ids in "m…

Interesting, I didn't knew that. I helped write a couple immediate-mode GUI some time ago, but I'm not deeply familiar with ImGui.

If this is the case, then it seems entirely possible to have an "internal retained mode", and might even help with some extra stuff like focus management and accessibility.

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

#79

Post by boomlinde »

ratww wrote: post #75
flohofwoe wrote: post #44

Earlier quoted context omitted.

Wouldn't it be possible to separate the public API from the internal implementation so much that the library appears "immediate mode" on the outside, but is completely "retained mode" on the inside? With a persistent widget tree which is only manipulated by diffing it against the current frame's UI description provided by the user code? The important feature of immediate mode UIs is that there's only one sequential p…

> Wouldn't it be possible to separate the public API from the internal implementation so much that the library appears "immediate mode" on the outside, but is completely "retained mode" on the inside? It is possible but you would need some severe API changes... you could either ask the users to use unique names for each widget, or something similar like storing references between frames. Alternatively you'd have to f…

I think the "virtual DOM" approach is more relevant part of React to look at to answer the question. The UI code appears immediate but on each invocation builds a data structure that represents the layout and references to data it depends on. The library consumes this data structure, compares it to its own internal, retained representation and adjusts the latter according to any changes that might have occurred. Input is consumed by the "retained mode" GUI toolkit, which triggers the immediate mode UI to re-render with return values from widgets adjusted according to the "immediate mode" result of the input.

The difference from React would be representational. In React you explicitly build this data structure as something resembling a DOM tree and handle input by attaching callbacks to nodes, but I think this representation is just convenient for web development rather than fundamental to the approach.

You might still need a way to manage updates to the state the GUI depends on and re-render when it changes for some other reason than an input operation.

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

#80

Post by pkphilip »

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…

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/

Post reply on HN