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

31–40 of 186 posts

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

#31

Post by reyqn »

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.

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

#32

Post by formerly_proven »

gambiting wrote: post #17
pansa2 wrote: post #14

Qt seems to be the most popular library for cross-platform GUI apps written in C++. Is Dear ImGui a credible alternative? How does Dear ImGui compare to Qt?

Well, these are as different as it gets. Dear ImGui is purely code based and it's drawing in immediate mode. Meaning there is no way to have a visual tool to arrange layouts for things, you have to do everything in code. It's fantastic for debugging, prototyping, very simple interfaces when that's all that's required, but it's not a fully fledged UI library like QT. It's like comparing a bicycle to a 4x4. Sure a bicy…

ImGui is not drawing in immediate mode (which isn't supported any more in any contemporary accelerated graphics API). Only the API is immediate mode. You can Begin() the same window multiple times and each time you do it during a frame you keep appending to the same window.

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

#33

Post by app4soft »

ejolto wrote: post #19
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…

the owner is french, I bet the french "cher imgui" reads better.

> the owner is french

Think, for #dearMoon[0] name "dear" refers to Jules Verne's "Rocket to the Moon".[1]

[0] https://twitter.com/dearmoonproject

[1] https://en.wikipedia.org/wiki/Jules_Verne%27s_Rocket_to_the_...

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

#35

Post by formerly_proven »

perfunctory wrote: post #6
dasloop wrote: post #4

The widget should keep its state private. ImGui::InputText("string", buf, IM_ARRAYSIZE(buf)); ImGui::SliderFloat("float", &f, 0.0f, 1.0f); And maybe is a C++ lib but the interface is C with namespaces. Odd.

The way I understand it, the idea is that widgets don't own the state. They are sort of stateless. Your app owns the state.

Exactly, the app owning (most of) the state is precisely the point of ImGui.

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

#36

Post by flohofwoe »

app4soft wrote: post #29

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

It's definitely possible but I guess nobody has done it yet because the usual GL "baseline" version these days is GLES2 (and that mostly because of WebGL). Each rendering command you get back from Dear ImGui comes with a block of vertices and indices. Typically those are stashed into 3D-API vertex- and index-buffers for efficient rendering, but they can just as well be "unrolled" to glBegin/End calls, it's just not as efficient. With a good GL driver this probably doesn't matter much though.

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

#38

Post by gambiting »

formerly_proven wrote: post #32
gambiting wrote: post #17

Earlier quoted context omitted.

Well, these are as different as it gets. Dear ImGui is purely code based and it's drawing in immediate mode. Meaning there is no way to have a visual tool to arrange layouts for things, you have to do everything in code. It's fantastic for debugging, prototyping, very simple interfaces when that's all that's required, but it's not a fully fledged UI library like QT. It's like comparing a bicycle to a 4x4. Sure a bicy…

ImGui is not drawing in immediate mode (which isn't supported any more in any contemporary accelerated graphics API). Only the API is immediate mode. You can Begin() the same window multiple times and each time you do it during a frame you keep appending to the same window.

Well yes, sorry, I misspoke.

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

#39

Post by exDM69 »

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 paradigm doesn't seem a very good fit.

I wish there was a retained mode GUI library that would be as easy to integrate in your game and graphics apps as ImGui (or nuklear) is.

On my spare time, I've been working on a retained mode GUI layout and rendering framework (not a complete GUI toolkit) that uses a DOM-like tree, CSS style flexbox layouts and produces a vertex buffer for rendering like ImGui does.

Unfortunately life gets in the way, and all I have to show for my project is a small prototype in C and another one in Rust (can't decide which I like more) that draws some text and rectangles with a fancy layout. Code is not public at the moment but I'm willing to share it with anyone (on GitHub) who responds with a thoughtful comment or a good question.

I have been following Raph Levien's fantastic work on Druid and Rust GUIs which has been very inspirational, this video in particular [0].

Where Raph is focused on native GUI rendering and high fidelity text output, I've only focused on rendering in a GPU application using shaders and only very basic text layout with simple kerning (like Dear ImGui).

As Raph points out in his later talks on the topic, layout and rendering are only half of the GUI puzzle. The other half is maintaining the state of the application, usually through some kind of widget tree.

Leave a comment if you're interested, I'd be happy to chat even though it doesn't seem like my projects are going anywhere anytime soon.

[0] https://www.youtube.com/watch?v=4YTfxresvS8 Data Oriented GUI in Rust by Raph Levien

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

#40

Post by flohofwoe »

formerly_proven wrote: post #32
gambiting wrote: post #17

Earlier quoted context omitted.

Well, these are as different as it gets. Dear ImGui is purely code based and it's drawing in immediate mode. Meaning there is no way to have a visual tool to arrange layouts for things, you have to do everything in code. It's fantastic for debugging, prototyping, very simple interfaces when that's all that's required, but it's not a fully fledged UI library like QT. It's like comparing a bicycle to a 4x4. Sure a bicy…

ImGui is not drawing in immediate mode (which isn't supported any more in any contemporary accelerated graphics API). Only the API is immediate mode. You can Begin() the same window multiple times and each time you do it during a frame you keep appending to the same window.

This point is so important that it bears repeating: only the programming model is "immediate", not the implementation under the hood.

Dear ImGui keeps (internal) state around between frames, maybe not as much as other UI frameworks, but it does. Especially the rendering isn't "immediate mode", the UI isn't rendered while running the code that's building the API. Instead Dear ImGui builds a "deferred mode" rendering command list which is actually very efficient in terms of required draw calls.

The main difference to traditional UI frameworks is that there are no different code paths for UI creation, UI updating, and handling input. Instead all those things are happening in the same sequential code flow.

Post reply on HN