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

11–20 of 128 posts

Re: Could ImGUI Be the Future of GUIs?

#11

Post by TazeTSchnitzel »

781 wrote: post #6

It's important to point out why games use immediate mode GUIs: 1. The GUI needs to be overlaid on the game image (OpenGL/DirectX). This is difficult with traditional GUIs like QT. 2. The GUI needs to be updated in sync with the game, again, it's difficult to integrate traditional GUIs event loops into the game loop, especially with stuff like double/triple buffering. 3. The GUI needs to be as fast as possible, games…

I think 1, 2 and maybe 3 could all be done with a traditional retained mode GUI, and indeed there are retained mode GUI systems for games. The big traditional UI frameworks just have not been made to work well with games. Which is fair, game engines are alien environments that may as well be considered their own platforms.

> It's worth pointing out that the immediate/retained split doesn't apply only to the GUI

Indeed. Modern game engines, and in particular almost all 3D games, use what could be described as a “retained mode” system for the rendering of the game itself — the scene graph — so it is interesting that the UI doesn't always match that.

Re: Could ImGUI Be the Future of GUIs?

#12

Post by TazeTSchnitzel »

mooman219 wrote: post #8

This is really reads like someone trying to sell you something. I've done work on frameworks for both immediate mode and retained mode GUIs. They both absolutely allocate memory behind the scene. There absolutely is state being marshaled around. Caching commonly used state is important. Performance can be bad and great in both. You're really just subscribing to different sets of opinions

Any moderately complex “immediate mode” GUI system is going to do something equivalent to constructing a “retained mode” GUI on the fly I'm guessing.

Re: Could ImGUI Be the Future of GUIs?

#13

Post by jayd16 »

781 wrote: post #6

It's important to point out why games use immediate mode GUIs: 1. The GUI needs to be overlaid on the game image (OpenGL/DirectX). This is difficult with traditional GUIs like QT. 2. The GUI needs to be updated in sync with the game, again, it's difficult to integrate traditional GUIs event loops into the game loop, especially with stuff like double/triple buffering. 3. The GUI needs to be as fast as possible, games…

Honestly, this is far too generous.

IMGUI is easy to implement so its the easiest to put in a custom game engine.

IMGUI is not particularly fast in practice. Unity's certainly isn't. However, they are simple, which approximates performance for small cases and it also lets you write your own tuned implementation.

Traditionally screen orientations for games were pretty simple so doing layouts in a single pass was feasible. These days, when you want to fit your game on every platform you need to do a lot of layout work. At that point you're just making an incomplete retained gui implementation.

Re: Could ImGUI Be the Future of GUIs?

#15

Post by arianvanp »

Recently I started playing with https://github.com/ajnsit/concur-documentation/blob/master/R... which has been the most refreshing UI paradigm i've used in a while. and it reminds me a lot of this ImGUI approach, but behind the scenes it uses coroutines instead.

The idea is that a button is a UI element that _blocks_ until an event is fired. You can then compose elements in time like:

    button "hey" >> label "clicked"
which is a program that displays a button, you click it, the button goes away and the text "clicked appears"

Or you can compose programs in space:

    (button "hey"  label "not clicked")
this is a program that displays both a button, and a label at the same time.

Now, by combining both space and time, we can create a program that changes the label when clicking as follows:

    program = (button "toggle"  label "off") >> (button "toggle"  label "on") >> program
This is an application that toggles a label on and off when you press a button. (Note that the definition is recursive)

Re: Could ImGUI Be the Future of GUIs?

#16

Post by theclaw »

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, and you're already expecting to redraw the whole screen every frame. It does not really suit more complex, text-heavy UIs where you're rendering thousands of glyphs with proper kerning and ligatures and anti-aliasing, etc, and want the result of that hard work to be retained in the framebuffer unless it absolutely needs to change.

Re: Could ImGUI Be the Future of GUIs?

#18

Post by RandyRanderson »

There's a difference bt poor impl and poor design.

As the author points out, HTML has a poor design (eg. if you want to have a 1000x1000 cell table, you have to have 10^6 actual cells - that's a lot of tds or whatever to parse).

Modern OO GUI frameworks don't do this - they say something like:

cellRenderer.draw(target, row,col,position,size)

No creation of objects required. Of course since it's so easy to create OO programs a lot of code isn't great... and then others copy that code and so it goes.

Seems like we keep re-creating software b/c we haven't taken the time to look at what exists and only then decide on what to keep and what to change. "This is too complex - I'll re-write it!". 10 years later: "We added all the features that the existing software had and now the new one... is just as slow... but we did sell a lot of conference tickets and books so... totally worth it."

When I was 20 I also thought I knew better so I get it.

Re: Could ImGUI Be the Future of GUIs?

#19

Post by pedrocr »

Conrod is an immediate mode GUI library for rust[1]. I've been using it for an image processing app[2] and have enjoyed the way the code turns out. Everything is much more straightforward as you don't have to reason about callbacks interacting with a loop that's not yours to control and the performance seems good.

[1] https://github.com/pistondevelopers/conrod

[2] https://github.com/pedrocr/chimper

Re: Could ImGUI Be the Future of GUIs?

#20

Post by pedrocr »

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

Post reply on HN