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

41–50 of 128 posts

Re: Could ImGUI Be the Future of GUIs?

#41

Post by tom_ »

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…

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,000 vertices/frame at 60Hz, and this is <2% of that. I struggle to believe this is any kind of an issue for anything modern.)

Re: Could ImGUI Be the Future of GUIs?

#42

Post by btown »

pciexpgpu wrote: post #21

The author does a good job explaining some benefits of an immediate mode renderer but vastly misses the disadvantages. The immediate mode renderer is great for toy programs. Similar to how you could reproduce 'look here is how simple it is to write hello world and compute the millionth digit of PI' in a new esoteric language... Occlusion, hit-testing, state changes, scrolling/animations even in the simplest forms wil…

In fact, with Javascript JIT engines (whose teams deeply understand the use of libraries like React) relentlessly attacking the overhead of DOM nodes and their initialization, and with users who actually expect the design flexibility provided by CSS... a system like React is actually an ideal layer of abstraction for modern UI implementation on practically any platform.

Sure, if you're on an embedded platform, somewhere a JIT can't run, or if you're doing something with real-time rendering requirements (and honestly modern React Suspense should even make that feasible), you may want to use something lower-level. But most people won't need to do this.

Re: Could ImGUI Be the Future of GUIs?

#43

Post by kuzehanka »

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…

Specifically Unity would have been much better served using something like Electron. Unity's UI looks bad, feels bad, and is a huge pain in the ass if you're authoring extensions.

Re: Could ImGUI Be the Future of GUIs?

#46

Post by nh2 »

> ... people scroll almost constantly in which case the ImGUI wins by a landslide

I think this is a misrepresentation of how fast scrolling is usually implemented.

For fast scrolling, you render the page (which is larger than the viewport = "what fits on the monitor") ONCE onto a GPU texture, and then all scolling happens on the GPU side (the CPU just tells the GPU the offsets into that texture).

Immediate mode has to recreate the texture every frame, instead of once for multiple frames. So "It might use more CPU" is quite certainly true.

Re: Could ImGUI Be the Future of GUIs?

#47

Post by nh2 »

nh2 wrote: post #46

> ... people scroll almost constantly in which case the ImGUI wins by a landslide I think this is a misrepresentation of how fast scrolling is usually implemented. For fast scrolling, you render the page (which is larger than the viewport = "what fits on the monitor") ONCE onto a GPU texture, and then all scolling happens on the GPU side (the CPU just tells the GPU the offsets into that texture). Immediate mode has t…

You can also do some simple math to arrive at a justification:

Assume a 4k x 2k display at 60 FPS.

Compute the throughput needed (Bytes per second) to draw an RGB framebuffer.

That is: 8M pixels x 3 Bytes x 60 fps = 1.44 GB/s

Note how we haven't done any computation yet to decide what the colours should be, this is just the CPU effort to do IO to tell the GPU about the new colours to show.

This would incur significant CPU usage, and your device would get hot quickly. In contrast, if you let the GPU scroll, you have to send two floats (for X and Y offset) per frame, and the GPU just does a hardware-parallelised lookup.

This is why we have GPUs, and why scrolling immediate-mode would make your device burning hot while a GPU does the task with minimal energy usage.

Re: Could ImGUI Be the Future of GUIs?

#48

Post by [deleted] »

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…

[deleted]

Re: Could ImGUI Be the Future of GUIs?

#49

Post by invokestatic »

tom_ wrote: post #41
invokestatic wrote: post #36

Earlier quoted context omitted.

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…

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.

Re: Could ImGUI Be the Future of GUIs?

#50

Post by amluto »

Here’s a downside that wasn’t mentioned:

    if (ImGUI::Button("Click Me")) {
        IWasClickedSoDoSomething();
    }
This forces Button to be stateless, which limits the possible quality of implementation. If you mouse-down on a button and the button changes before you mouse-up, it shouldn’t register as a click. Similarly, if you mouse-down on a button, drag to the button, and mouse-up, it shouldn’t be a click. Implementing this in a fully immediate-mode GUI with this interface is either impossible or requires gross hacks.
Post reply on HN