Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Could ImGUI Be the Future of GUIs?

games.greggman.com

Post reply on HN
Print view View original

111–120 of 128 posts

Re: Could ImGUI Be the Future of GUIs?

#111

Post by tom_ »

Keyframe wrote: post #104
loup-vaillant wrote: post #89

Earlier quoted context omitted.

Arenas are the simplest allocation scheme ever. // Start of frame void *arena = malloc(LOTS_OF_MEMORY); void *next_ptr = arena; // Allocate something object = *next_ptr; // return that value next_ptr = object_size + alignment; // crash if out of memory // End of frame free(arena); By the way, such "separate complex ad hoc" memory allocation schemes are the reason why manual memory management is faster than garbage co…

No need to malloc each frame. Malloc at startup and memset each frame (don't even need to do that, tbh).

It’s a good idea to have a mode that does malloc every frame, as that makes stale pointers much easier to find.

Re: Could ImGUI Be the Future of GUIs?

#112

Post by tom_ »

analognoise wrote: post #69
jbverschoor wrote: post #14

Can we please just stop moving around in circles in the tech industry? Nobody seems to learn anything from past methods, tech and everything.

LOL. My favorite part of it was the last line: "More research into ImGUI style UIs could lead to huge gains in productivity." Don't tell this cat that the research on this stuff goes back >40 years and that the introductory chapter of any book on computer graphics would have talked about all of this. Not like it would help him - he hasn't read anything about it, didn't even do a cursory Google search. Sheesh. A low,…

Do you have any recommended links?

Re: Could ImGUI Be the Future of GUIs?

#113

Post by brann0 »

invokestatic wrote: post #36
tom_ wrote: post #33

Earlier quoted context omitted.

I've written real-time game UIs too. I think you underestimate just how ludicrously fast CPUs and GPUs are, and overestimate the complexity of your average GUI. What does your average screen's-worth of GUI consist of, after all? How many widgets are there? I double dare you to tell me that a modern computer or games console can't handle 500 widgets per frame. And I now triple dare you to tell me that your UI designer…

I'm sure many games can get away very well with an immediate mode GUI. I think the question is not can you, but rather should you. My last project used a custom immediate-mode GUI. At the absolute pinnacle of optimization, it was pushing 2,000+ FPS on my machine with something like 3-4k vertices, with heavy texture mapping and anti-aliasing. But the problem was that even with peak optimization, the CPU was spending 1…

Performance is not the only consideration, even in most demanding games. IM GUIs simplify UI code a lot, by not having to rely on message systems that make the code harder to follow and less predictable.

As most things in life, it's a matter of trade-offs.

Re: Could ImGUI Be the Future of GUIs?

#114

Post by brann0 »

geezerjay wrote: post #83
josephg wrote: post #37

Earlier quoted context omitted.

On the allocation point, the efficient way to handle this is to use a per-frame memory pool. Because nothing in the IMGUI can persist between frames, you can allocate a single arena of memory for any UI elements that need to store bounding boxes or callbacks or whatever. Each frame just reset your next_ptr to the start of the arena. Technically you are allocating memory, but in practice your allocations are free.

Adding a separate complex ad hoc memory allocation scheme is not what I would call free. Granted, computationally-wise it may be relatively cheap but it does add multiple forms of complexity to a problem that doesn't exist in rmguis.

A memory arena that is reset every render loop is the simplest memory allocation possible.

Re: Could ImGUI Be the Future of GUIs?

#115

Post by brann0 »

laythea wrote: post #95

I got fed up of ImGUI when I wanted to route events to my application instead of the GUI. Its good "out the box" ut when you need to get down and dirty to customise, it can be awkward. Nowadays I do a hybrid approach, so I have use NanoGUI and create my own "live data" "retained mode" controls. Now I have either the best of both worlds or the worst of both worlds. I think the best: Pros: - I don't have to bother with…

You seem to be missing the point of IM GUIs. They are just intended to render the UI in a stateless way. If you try to use them in another way you'll find them awkward, of course.

I may have misunderstood you, tho :)

Re: Could ImGUI Be the Future of GUIs?

#116

Post by ahaferburg »

From dear ImGui's mission statement:

> Designed for developers and content-creators, not the typical end-user! Some of the weaknesses includes:

> - Doesn't look fancy, doesn't animate.

> - Limited layout features, intricate layouts are typically crafted in code.

It may not replace retained mode GUI toolkits, but it can certainly make the life of devs easier. If all you need is to quickly hack together an internal tool, or some quick debugging interface, keep ImGui in mind.

Re: Could ImGUI Be the Future of GUIs?

#117

Post by sly010 »

josephg wrote: post #37
overgard wrote: post #25

Really probably not. I love them and they're very handy in certain situations (debugging tools, quick UIs) but once you need a lot of customization they become extremely cumbersome. Also really kind of makes it impossible for designers or less technical people to do anything. Also, while I think separating view logic is slightly overrated, it is useful, and it's very hard to do that with IMGUI. Also it doesn't thread…

On the allocation point, the efficient way to handle this is to use a per-frame memory pool. Because nothing in the IMGUI can persist between frames, you can allocate a single arena of memory for any UI elements that need to store bounding boxes or callbacks or whatever. Each frame just reset your next_ptr to the start of the arena. Technically you are allocating memory, but in practice your allocations are free.

Where do you store pointers to textures? Or do you upload textured to the GPU every frame? What about scroll positions an other non application state?

Re: Could ImGUI Be the Future of GUIs?

#118

Post by sly010 »

pedrocr wrote: post #20
theclaw wrote: post #16

In the context of creating debugging UIs for games and graphics applications, Dear imGUI is a godsend. Programmers love it because there is literally only the code to worry about. It's very easy to get it up and running, and all the code that handles the UI drawing and interaction is in one place so it's easy to reason about. It works very well in the context where you already have fast graphics and an update loop, a…

> want the result of that hard work to be retained in the framebuffer unless it absolutely needs to change I think immediate mode GUI libraries can get around this issue by still caching and reusing between frames. Conrod does this by still having the state in the background although you are programming to an immediate mode API: https://docs.rs/conrod/latest/conrod/guide/chapter_1/index.h...

That's a bit antithetical, given the other side of the debate being Retained Mode GUIs.

That said it's a good middle ground. Use whatever API you prefer over a well optimized implementation.

Re: Could ImGUI Be the Future of GUIs?

#119

Post by HelloNurse »

amluto wrote: post #66
bdowling wrote: post #56

Earlier quoted context omitted.

A naive implementation would have the problem you describe. However, a smarter library implementation avoids this (e.g., by generating an id for the button, saving the id on mouse-down, and checking the id on mouse-up). The user of such a library won't have to worry about it.

And how, exactly, is the id created? Some hash of the button’s text and coordinates? I would call that a dirty hack, no to mention being implicitly stateful.

But a stateful GUI is not a sin: the program as a whole has state, application code needs to process GUI inputs to update application-level state (e.g. currently set game options) while tracking mechanical details like whether a button is "half clicked" is suitable for automation at the GUI library level.

Regarding IDs, they can (and must) be provided by client code, as client code is responsible for managing widget identity (i.e. whether the button that might have a mouse up event this frame is "the same" that received a mouse down event some frames ago). In C or C++, string names could usually be autogenerated with trivial macros relying on __LINE__ and __FILE__.

Re: Could ImGUI Be the Future of GUIs?

#120

Post by analognoise »

tom_ wrote: post #112
analognoise wrote: post #69

Earlier quoted context omitted.

LOL. My favorite part of it was the last line: "More research into ImGUI style UIs could lead to huge gains in productivity." Don't tell this cat that the research on this stuff goes back >40 years and that the introductory chapter of any book on computer graphics would have talked about all of this. Not like it would help him - he hasn't read anything about it, didn't even do a cursory Google search. Sheesh. A low,…

Do you have any recommended links?

I do!

One of my favorite is "Don't Fidget with Widgets, Draw!" (https://www.hpl.hp.com/techreports/Compaq-DEC/WRL-91-6.pdf) It's modern enough to be understandable, and while it's referencing Ezd (a Scheme drawing system) it greatly influenced Tk (which is still used in all kinds of heavy-hitting EDA software).

That one's only been around for 28 years though (well, the paper was published in 1991, so code was before that...) but let's go further:

The drawing system(s) that greatly influenced Ezd came largely from Xerox PARC, such as ALTO: https://www.computerhistory.org/atchm/xerox-alto-source-code...

There's code in there for a vector drawing program (in 1980!), as well as interacting widgets. Let's go back further...

Finally, we have to mention the Mother of All Demos, in 1968: https://en.wikipedia.org/wiki/The_Mother_of_All_Demos

Which if you haven't watched MOAD before, give it a spin. It will still blow your mind, but the interactive graphical drawing mechanisms will be recognizable.

Also, this "paint the screen every time" method is how a tremendous number of people who cut their teeth on DOS did things on the screen. DOS release date: 1981. So you don't have to have been an academic (which I am NOT) to have tried these techniques while solving practical problems.

As far as books: Computer Graphics Principles and Practice in C (later editions use C#/C++/etc. - the ideas are the same)

The 1995/96 one talks about retained mode graphics directly. That book has been standard in "intro computer graphics" courses for as long as it's been out. So at least 20+ years it's been the "start here" book.

So yea, this stuff has been around for a while...

Post reply on HN