Live data from Hacker News

Could ImGUI Be the Future of GUIs?

games.greggman.com

1–10 of 128 posts

Re: Could ImGUI Be the Future of GUIs?

#5
I think the author is over exaggerating the problem of object creation and destruction in traditional gui frameworks. List/collection views are designed to reuse objects as you scroll. Secondly I think the author is also downplaying the fact that retained GUIs can also cache object rendering. Just as the gpu doesn't have to draw the whole screen when only the cursor is blinking, it also doesn't have to redraw widgets unless their size changes.

Immediate vs retained is a simple case of budgeting against cpu usage or memory usage, and it should be considered in that light. (immediate uses more processing, retained uses more memory)

Re: Could ImGUI Be the Future of GUIs?

#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 are severely CPU bound.

A retained mode GUI is typically easier to use, convenience is not why people use immediate mode GUIs.

It's worth pointing out that the immediate/retained split doesn't apply only to the GUI - there are retained mode graphical APIs - DirectX used to have one. They are only used in low-demand games, they sacrifice a lot of speed for the convenience of using a retained mode.

Re: Could ImGUI Be the Future of GUIs?

#7
> A few problems with this GUI style are:

> You have to write lots of code to manage the the creation and destruction of GUI objects. [..]

> The creation and destruction problem leads to slow unresponsive UIs [..]

> You have to marshal your data into and out of the widgets. [..]

My biggest pain point with the retained mode GUIs I worked with was none of the issues mentioned above. It was always the centralized GUI thread and the consequential synchronization complications. I don't know if this is an inherent problem of retained mode GUI frameworks and if there are some that don't force all widgets into a single thread. If not, this alone is a reason to for me to find immediate mode interesting.

Re: Could ImGUI Be the Future of GUIs?

#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

Re: Could ImGUI Be the Future of GUIs?

#9
I recall reading this article in your comments on the last GUI-specific link posted here... where you just kept disagreeing with comments that took the time to point out how this stuff is largely off base.

We moved away from WM_PAINT for a reason.

Re: Could ImGUI Be the Future of GUIs?

#10

I think the author is over exaggerating the problem of object creation and destruction in traditional gui frameworks. List/collection views are designed to reuse objects as you scroll. Secondly I think the author is also downplaying the fact that retained GUIs can also cache object rendering. Just as the gpu doesn't have to draw the whole screen when only the cursor is blinking, it also doesn't have to redraw widgets…

Thinking about this decision just as a performance one disregards the fact that the code is substantially different. It does seems likely that one way is more intuitive / easier to work with than the other, I wouldn't know which though.
Post reply on HN