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

111–120 of 186 posts

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

#111

Post by robinei »

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.

I'm not convinced that redrawing on input events is especially inefficient. No need to redraw continuously.

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

#112

Post by Rusky »

FraKtus wrote: post #102
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.

It's not related. The "page tearing" problem is caused by the way imgui handles events.

You describe the UI by making a bunch of function calls, each of which immediately renders a piece of the UI and returns any relevant events (e.g. render a button, return whether it has been clicked). But this means that any event that should change how the UI is rendered may have missed its chance- what if the changed part of the UI has already had its function called that frame?

The "ideal" dataflow, as far as this problem is concerned, would be to fully process all the events in a frame (from raw input, to widget-level events like button presses, to application-specific stuff) before rendering anything.

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

#113

Post by tom_ »

phkahler wrote: post #109

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

If you are already using qt, gtk or wx, then dear imgui is not really aimed at you. The intended use case is more the situation where you already have what you term the backend, and you want to add a gui to your program.

(There's not much that's platform-specific in dear imgui, so you end up with a GUI that's as multiplatform as your program is.)

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

#114

Post by account42 »

greggman3 wrote: post #47
app4soft wrote: post #29

Is there usable Dear ImGui fork/sample for OpenGL 1.x ?

All Dear ImGUI does is generate arrays of vertices + texture coordinates. That's it. It doesn't support any particular graphics API. There are examples in the repo but they are just that, examples. If you want to use it in OpenGL 1.0 it shouldn't take you more than a few minutes.

It definitely does come with backends for various APIs: https://github.com/ocornut/imgui/tree/master/backends

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

#115

Post by flohofwoe »

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

This would also drastically improve the accessibility situation for games!

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

#116

Post by aquova »

I'm curious on what opinions are on Dear ImGui's bindings in other languages, namely Rust. imgui-rs seems to be one of the only mature-ish GUI libraries, but I found myself struggling with it. The multiple window "debug view" looks great, but for something like an OpenGL window with a simple menu bar, I found it difficult to create. There is also apparently no file picker widget, which I found to be a big downside.

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

#117

Post by [deleted] »

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.

[deleted]

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

#118

Post by 10000truths »

enriquto wrote: post #95
pkphilip wrote: post #86

Earlier quoted context omitted.

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

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

#119

Post by ratww »

mwcampbell wrote: post #106
ocornut wrote: post #100

Earlier quoted context omitted.

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…

Just better documentation, tutorials and samples would improve the situation 100x! The current ones are hard even for veteran native programmers.

Next thing I'd love to see would be a simplified API to allow smaller developers to also use it. As it is, only giant companies can afford handling accessibility.

A personal wish would be to have an immediate mode imperative API for accessibility that abstracts the Automation Tree. Similar to how Dear ImGui does. Something like: BeginFrame, TextInput, Checkbox, EndFrame, etc... plus some commands to "ask" if the Automation API wants to do something, like moving to the next control. Maybe a Dear ImAccessibility?

This would work perfectly for Video Games and would allow accessibility to added even to games that didn't predict it. Games are pretty simple, and don't require too much variety. I worked in an Adventure Game in the past and it would be 100% playable using A11y with something like that. I would love to make a 100% accessible game in the future.

This of course could be a simple multi-platform wrapper instead of something from your team.

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

#120

Post by lenkite »

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…

How about this one: https://github.com/cycfi/elements ?
Post reply on HN