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

101–110 of 186 posts

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

#101

Post by CyberDildonics »

JabavuAdams wrote: post #92
DethNinja wrote: post #88

Earlier quoted context omitted.

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.

Cursors are done with hardware cursor sprites on the video card and so run perfectly at the full frame rate of the monitor. In game cursors will be different.

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

#102

Post by FraKtus »

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…

Maybe it is still VBL related, in the DX11 sample you will see this when presenting the final frame:

g_pSwapChain->Present(1, 0); // Present with vsync

//g_pSwapChain->Present(0, 0); // Present without vsync

So you can control this by setting the first argument to 1 or 0.

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

#103

Post by userbinator »

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.

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

#104

Post by [deleted] »

MattRix wrote: post #99
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)

[deleted]

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

#105

Post by raphlinus »

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…

Thanks for the kind words. My thinking has evolved since that video; my blog at https://raphlinus.github.io/ is a good place to check.

As flohofwoe suggests in a sibling, combining an imgui-like API with an actual retained widget tree would be something of the best of both worlds. That is indeed pretty close to what the Crochet prototype does. We're not trying to exactly match the imgui but it's pretty close. In particular, getting actions back from widgets (like button presses) is the return value from calling the widget-creating function. That's a notable difference from, say, Jetpack Compose, which is fairly imgui-like on widget creation but pretty much uses callbacks for those actions. Crochet does solve the page tearing problem (though the current implementation is hacky, don't look too closely under the hood).

Another note - the Dear ImGui implementation has become a lot more sophisticated over the years, and is no longer a simplistic implementation of the immediate mode GUI concept. It has unique id's for widgets, its text processing has become better, etc.

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

#106

Post by mwcampbell »

ocornut wrote: post #100
mwcampbell wrote: post #85

Earlier quoted context omitted.

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

That's a fair request. All of the full-featured accessibility implementations are buried in complex UI frameworks and browser engines. I'm also aware that the sample UIA provider implementations in the Windows SDK aren't very useful; they all implement a single control in its own HWND, using GDI or GDI+.

As part of Microsoft's Hack for Good program, I worked with the developers of the Quorum language and development environment (https://quorumlanguage.com/) on their UIA implementation. So I know how frustrating it can be for a non-expert to implement UIA, and how easy it is to get it wrong.

I'll have to see what I can do about implementing a better sample.

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

#107

Post by varispeed »

softawre wrote: post #98
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.

It looks very impressive indeed! I may be giving it a go in the near future as I may have an use case for it.

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

#109

Post by phkahler »

>> You will need a backend to integrate Dear ImGui in your app. The backend passes mouse/keyboard/gamepad inputs and variety of settings to Dear ImGui, and is in charge of rendering the resulting vertices

Some people say this thing is platform agnostic, which is sort of true. But in no way does it give you a multiplatform GUI. You must provide this "backend" for every OS you want to run on. If you decide to handle that with QT, GTK, or WX, then what use is this?

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

#110

Post by HelloNurse »

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…

Two label that should have the same value are normally one too many, but if they are needed it is often possible to order them properly...

    //initialization
    int counter=0;
    //each frame
    label("count: %d\n", counter);
    label("count again, in case you missed the other label: %d\n", counter);
    if(button("increase")) { counter += 1; }
or, if the order of widgets is constrained, to buffer values:

    //initialization
    int counter_old=0;
    int counter_new=0;
    //each frame
    counter_old = counter_new;
    label("count: %d\n", counter_old);
    if(button("increase")) { counter_new = counter_old+1; }
    if(button("decrease")) { counter_new = counter_old-1; }
    label("count again, in case you missed the other label: %d\n", counter_old);
Post reply on HN