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

181–186 of 186 posts

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

#181

Post by doctorgester »

exDM69 wrote: post #179
moonchild wrote: post #168

Earlier quoted context omitted.

Imgui has problems, but this isn't one of them. Your retained-mode GUI framework isn't doing dirty rectangles anymore anyway ; it's going to redraw everything anyway. (Not every frame, but upon receiving an event.) With modern GPUs, redrawing a whole frame is super cheap , even with integrated graphics. The gain, then, is going to come from not having to rebuild the scene graph every frame. And modern imgui implement…

> Your retained-mode GUI framework isn't doing dirty rectangles anymore anyway; it's going to redraw everything anyway. (Not every frame, but upon receiving an event.) Except that a a retained mode GUI can easily tell that no redraw is necessary and it will be a no-op. > With modern GPUs, redrawing a whole frame is super cheap, even with integrated graphics. It's cheap as in fast, but it's not cheap in power consumpt…

> Except that a a retained mode GUI can easily tell that no redraw is necessary and it will be a no-op.

How is that different from imgui exactly? Both dirty rect invalidation and the following redraw skipping is incredibly easy to do (and has been done, see microui)

> Rebuilding a scene graph that's based on CSS-style flexbox layout is REALLY fast. It's a linear time operation in the worst case and a lot of the work can be just skipped if the layout doesn't need updating.

I'm not sure what are the numbers there, but my fullscreen imgui application (You can see it here https://twitter.com/DoctorGester/status/1022147094558269446 and there are views with more complex layouts, rich text rendering, etc) hacked on top of DearIMGUI takes 0.2ms (200 microseconds) per frame, that is including all the logic and submission of commands to the GPU backend. That's before any optimization or multithreading independent views. Do you really get much faster than that?

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

#182

Post by ocornut »

programd wrote: post #150
phkahler wrote: post #148

Earlier quoted context omitted.

That might be a good idea. I hadn't thought of SDL which would provide a bare minimum to get cross platform.

Here is a writeup from someone trying to get SDL to work with Dear ImGui. It kind of works, but... https://retifrav.github.io/blog/2019/05/26/sdl-imgui/ You can feel this persons frustration about all the obscure magic incantations needed to get a simple GUI and some lines on screen. The really awful part is the last bits where he discusses how to get the damn thing compiled on Win/Linux/Mac. Even installing all the…

> You can feel this persons frustration about all the obscure magic incantations needed to get a simple GUI and some lines on screen.

The vast majority is setting up SDL with a graphics context - anything graphics in C++ land is notoriously tedious, yes - not much of that is in control of Dear ImGui.

If you look at "Plugging Dear ImGui into SDL" there's a total of 14 lines involved in adding Dear ImGui over an existing SDL+OpenGL application, which is the precise target use of Dear Imgui.

Here are the lines:

  // Init
  IMGUI_CHECKVERSION();
  ImGui::CreateContext();
  ImGui::StyleColorsDark();
  ImGui_ImplSDL2_InitForOpenGL(window, gl_context);
  ImGui_ImplOpenGL3_Init(glsl_version.c_str());

  // Event forwarding
  ImGui_ImplSDL2_ProcessEvent(&event);

  // New frame
  ImGui_ImplOpenGL3_NewFrame();
  ImGui_ImplSDL2_NewFrame(window);
  ImGui::NewFrame();

  // Rendering
  ImGui::Render();
  ImGui_ImplOpenGL3_RenderDrawData(ImGui::GetDrawData());

  // Shutdown
  ImGui_ImplOpenGL3_Shutdown();
  ImGui_ImplSDL2_Shutdown();
  ImGui::DestroyContext();
Everything else is setup that has nothing to do with dear imgui, or excess dear imgui usage demo from that article. I'm not sure it's possible to make it any easier other that adding a wrapper across all back-ends.

Yes, setting up graphics stuff in C++ is not trivial, but that's not Dear ImGui fault.

> Only a masochist would love this - which to be fair, probably describes game developers as a group.

Yes. Game developers are people who can have GTA5 running on a PS3, a console with 256x2 MB of RAM, while web applications displaying a chat frequently use more memory than that. I guess you call it masochist, I call it being efficient and excellent.

https://www.youtube.com/watch?v=d0KJhFMnWRI

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

#183

Post by JabavuAdams »

eska wrote: post #151
JabavuAdams wrote: post #90

Earlier quoted context omitted.

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.

I think if it as Casey Muratori's "brain fart" that made sense in his context [...] I have massive respect for him, [...] Sure doesn't sound like it. You're so dismissive of others' ideas that I don't even feel like you're looking for a constructive discussion.

Not sure why you would conclude that from what I wrote. I see myself as adding historical context + usage experience.

EDIT> I've learned a bunch from this discussion, and I haven't directly refuted much of it, just added commentary.

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

#184

Post by greggman3 »

account42 wrote: post #114
greggman3 wrote: post #47

Earlier quoted context omitted.

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

Those are examples. They are not Dear ImGUI. Dear ImGUI is 2 files, that's it. The rest is just examples of how to integrate it. If you can't figure out hot to draw a list of vertices with texture coordinates in any API then you probably aren't the target for Dear ImGUI

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

#185

Post by yvt »

moonchild wrote: post #168
userbinator wrote: post #103

Earlier quoted context omitted.

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.

Imgui has problems, but this isn't one of them. Your retained-mode GUI framework isn't doing dirty rectangles anymore anyway ; it's going to redraw everything anyway. (Not every frame, but upon receiving an event.) With modern GPUs, redrawing a whole frame is super cheap , even with integrated graphics. The gain, then, is going to come from not having to rebuild the scene graph every frame. And modern imgui implement…

> Your retained-mode GUI framework isn't doing dirty rectangles anymore anyway; it's going to redraw everything anyway.

Does this refer to the one presented in the top-level comment or a retained-mode GUI framework in general (like GTK)? Because it's usually not true for the latter.

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

#186

Post by greggman3 »

Torkel wrote: post #61
greggman3 wrote: post #43

Earlier quoted context omitted.

As much as I love Dear ImGUI it's arguably not a good UI for user-facing apps (vs dev team apps) Supporting all of unicode, all IMEs, emoji, right-to-left languages, etc. is arguably out of scope for Dear ImGUI.

Well, maybe. We use it user-facing for suite of niche vr/tele-op applications and it works wonderfully. We have support for Korean, Japanese, Hebrew (serious issues with right-to-left in our implementation though). The thing about ImGui is it puts devs on steroids - adding gui is just sooo fast. And fun. And easy to tweak. And easy to debug. 10X, maybe? I get that for a game maybe the user facing gui is less of an is…

You have support for Korean and Japanese and Hebrew. How about the rest of unicode? My guess is you have a static or fixed size texture atlas. To put all 140k glyphs of unicode in a single texture atlas would require a 12k by 12k texture assuming 32x32 pixel glyphs. Plenty of devices don't support textures of that size and you'd be limited to just that size of font. Handling this in an actually "all of unicode" way so a user can read documents and type names in all the languages etc ("use facing apps") is not something Dear ImGUI as currently designed can handle AFAIK. It's not just a PR waiting to be written, it would be a large change.

There are other issues with ImGUI paradigm as well. How does it handle accessibility for example. With OS level widgets the OS itself can read the content and deal with accessibility. Same with HTML. But with entirely internal data and just a list of GPU commands that's a huge open issue.

I'm a HUGE fan of Dear ImGUI and have donated $$$$ to it. I think it's awesome. I think there is lots of room and inspiration to be had from Dear ImGUI for making it easier to make UIs. I've written articles on it (https://games.greggman.com/game/imgui-future/) But I'm not blind to its current limits

Post reply on HN