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

101–110 of 128 posts

Re: Could ImGUI Be the Future of GUIs?

#101

Post by ahaferburg »

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…

This is the exact issue I'm running into right now with dear ImGui. There is no event propagation. You can either transfer control over to ImGui, or you retain control. In Qt it would be possible for the focus widget to not accept events, so they would bubble up the hierarchy. Considering how the hierarchy is tied to the callstack, this seems difficult to achieve with an ImGui.

Re: Could ImGUI Be the Future of GUIs?

#102

Post by laythea »

ahaferburg wrote: post #101
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…

This is the exact issue I'm running into right now with dear ImGui. There is no event propagation. You can either transfer control over to ImGui, or you retain control. In Qt it would be possible for the focus widget to not accept events, so they would bubble up the hierarchy. Considering how the hierarchy is tied to the callstack, this seems difficult to achieve with an ImGui.

NanoGUI + live data custom controls = happy days

Re: Could ImGUI Be the Future of GUIs?

#103

Post by MarceColl »

invokestatic wrote: post #49
tom_ wrote: post #41

Earlier quoted context omitted.

I don't understand the problem. 2000Hz = 0.5ms/frame; 20% of this = 0.1ms. That sounds like a great result. Your target frame rate is presumably 60-100Hz, assuming it's a PC game, meaning your frame budget is 10-16ms. If your UI takes 0.1ms, you've got >99% of your budget left. (Also: 3-4K vertices for UI was about what you could expect to budget for a PS2 or Xbox game! - max throughput for PS2 was something like 250…

I should mention that 2000 Hz when only running the UI -- with the full game running at 150 FPS. So really the CPU time is 6.66ms*0.2 = 1.33 ms just for the UI! Of course, that's on my beefy machine with a octo-core overclocked CPU and a couple 1080Tis. But what about the players who are trying to play on their mobile CPUs with integrated graphics? That margin could be the difference between 45 and 60 FPS.

This is wrong, just because it uses 20% CPU when rendering at 2000Hz doesn't mean it will consume 20% CPU when running the game too. Running the game alongside the UI is what makes it drop to 150FPS from 2000FPS. So if the UI consumes the 20% of the frame time at 2000FPS, that is indeed 0.1ms and this number will not magically increase when you add the game. So when you're running at 150FPS your frame time is 6.66ms and you're using 0.1 for the UI. That seems pretty good for me to be honest.

Re: Could ImGUI Be the Future of GUIs?

#104

Post by Keyframe »

loup-vaillant wrote: post #89
geezerjay wrote: post #83

Earlier quoted context omitted.

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.

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

Re: Could ImGUI Be the Future of GUIs?

#105

Post by floatboth »

revvx wrote: post #58
627467 wrote: post #44

I'm having a hard time to understand what is ImGUI (and what is the opposite RmGUI)... any could help me with ELI5? It sounds like ImGUI is reactive while RmGUI is not?

Games (normally) re-render the whole scene every frame. ImGUI exposes that to their API users: you have to re-render and check for clicks on every frame. The code looks like React, (but not as optimized, it re-renders every frame!), and normally you have to keep state by yourself. Code example: [1]. Retained Mode is closer to the DOM, Cocoa or WPF: you create objects and there's an abstraction between the API and the…

> Games (normally) re-render the whole scene every frame

They don't re-upload the whole scene to the GPU every frame, they don't recreate objects all the time. Immediate mode was only used in, like, the GL 1.x times.

Re: Could ImGUI Be the Future of GUIs?

#106

Post by floatboth »

etaioinshrdlu wrote: post #53

Didn't Firefox put forward a big plan to basically implement the browser as an immediate mode UI designed to redraw everything on every frame?

WebRender is not just a "plan" but a real thing (I'm using it right now), and it's fully retained.

Immediate doesn't mean just redrawing everything on every frame, immediate means what's described in the article — not keeping state. WR aggressively relies on kept state to optimize rendering of each frame as much as possible.

Re: Could ImGUI Be the Future of GUIs?

#107

Post by maccard »

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

Nope, just set the pointer back to where it started from. You do need to be super careful doing this though, as anything that relies on RAII (in c++ land) will be busted. You could manually call the destructor on the object in that case, but kind of defeats the purpose of the "no allocation" goals

Re: Could ImGUI Be the Future of GUIs?

#108

Post by benj111 »

gmueckl wrote: post #92
benj111 wrote: post #86

Earlier quoted context omitted.

>Why settle for "good-enough" performance? Because its good enough? Perfection is the enemy good. I can't see 2000 FPS, 60 FPS is good enough for me. Similarly the 20% vertex buffer hit might not matter.

The catch is that games follow the law of "MOAR!": more details, more effects, more postprocessing, mpre abimation, more simulation... this means that the engine will almost always be pushed to max out the hardware long before the designers are happy with what they have. Heck, I can think of pretty easy ways to improve sound and video quality of games in ways that are quite fundamental, but that would easily max out…

Perhaps you're right. As you can probably tell from my prior comment, I don't really subscribe to the 'MOAR' philosophy.

Re: Could ImGUI Be the Future of GUIs?

#109

Post by sago »

I have implemented a bunch of UIs for games. Immediate mode sounds good, but each time the thing that has bit me has been layout.

Sometimes you need to traverse the hierarchy to figure out where things will be placed. Before traversing it for render. If your hierarchy is implicit in a call graph, you have to either duplicate your calls, or implement some kind of backend retained system so you can defer rendering until after layout.

Beyond the absolute simplest of toy UIs, immediate mode doesn't work in my opinion.

Re: Could ImGUI Be the Future of GUIs?

#110

Post by golergka »

Every time a developer decries some abstractions and tools as unnecessary complicated and too "enterprise", it probably means he haven't encountered a problem that this solution was created to address.

As a Unity developer, I love immediate mode GUI for debugging. But I would never in my right mind attempt to use it for actual in-game GUI. Project I'm working on right now is not incredibly complicated, it's just a typical mobile match3 game. But a typical screen here has: (1) background that has to be scaled over all screen, eveloping it around while keeping aspect ratio, (2) frame that has to be scaled to screen without keeping aspect ratio, (3) a "window" background that has to be scaled somewhat to screen (with margin), being enveloped by it, (4) interactive elements, that have to be scaled down from the "safe area" (so that there are no button under the iPhone bevel), (5) match3 game field that has to be scaled according to physical sizes of the screen, (6) pixel-perfect elements that have to be chosen according to pixel size of the screen (1x, 2x and 3x options) and scaled appropriately.

So, no, immediate GUI is definitely not the solution here.

Post reply on HN