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

71–80 of 128 posts

Re: Could ImGUI Be the Future of GUIs?

#71

Post by smallnamespace »

revvx wrote: post #63
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…

> The CPU was spending 15-20% of its time every frame recreating the UI's vertex buffer. Not saying it is easy, but it's possible to optimize and cache vertex buffers by using something similar to React's VDOM.

Doesn't your cache just become a limited retained mode with a somewhat hacky, opaque API?

Re: Could ImGUI Be the Future of GUIs?

#72

Post by learc83 »

kuzehanka wrote: post #43
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.

2019.1 has a new retained mode editor UI system based on CSS.

Re: Could ImGUI Be the Future of GUIs?

#73

Post by DougBTX »

smallnamespace wrote: post #71
revvx wrote: post #63

Earlier quoted context omitted.

> The CPU was spending 15-20% of its time every frame recreating the UI's vertex buffer. Not saying it is easy, but it's possible to optimize and cache vertex buffers by using something similar to React's VDOM.

Doesn't your cache just become a limited retained mode with a somewhat hacky, opaque API?

Basically yes. If an immediate mode API is much easier to use, and a retained mode underlying implementation has much better performance, then putting a React-style VDOM layer in-between could get the best of both worlds, depending on how well the middle layer is implemented.

Re: Could ImGUI Be the Future of GUIs?

#74

Post by overgard »

btown wrote: post #42
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, somewh…

The DOM being slow is really more an artifact of browsers/HTML and the history behind doing document based layout. React is a nice solution to that specific problem; but this article suggests immediate mode gui's are the future, which, I don't think that's really the case. And I'm not sure I'd really call React an IMGUI anyway. It's similar, but it's also pretty different.

Re: Could ImGUI Be the Future of GUIs?

#75

Post by forrestthewoods »

jrk wrote: post #68
forrestthewoods wrote: post #62

Earlier quoted context omitted.

Whoa there. Electron is a catastrophic of hog of resources and performance. Electron for mobile game UI would be a disaster!

This is referring to Electron for the (PC-based) editor UI, not the deployed game UI. (Plenty of criticisms of Electron still hold, of course.)

Ah, that's fair.

Unity launched in 2005. Electron released in 2013. Still, saying Unity would have been "better served" by using Electron is more than a little unreasonable!

Using a primarily JavaScript environment for primarily C# content sounds like an absolute nightmare to me.

Re: Could ImGUI Be the Future of GUIs?

#76

Post by [deleted] »

smallnamespace wrote: post #71
revvx wrote: post #63

Earlier quoted context omitted.

> The CPU was spending 15-20% of its time every frame recreating the UI's vertex buffer. Not saying it is easy, but it's possible to optimize and cache vertex buffers by using something similar to React's VDOM.

Doesn't your cache just become a limited retained mode with a somewhat hacky, opaque API?

[deleted]

Re: Could ImGUI Be the Future of GUIs?

#77

Post by c-smile »

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…

> This is difficult with traditional GUIs like QT.

That's not actually that hard to do. You just need to split the UI on layers.

Here is for example HTML/CSS is rendered below and on top of 3D scene: https://sciter.com/sciter-and-directx/

Re: Could ImGUI Be the Future of GUIs?

#80

Post by pjmlp »

detaro wrote: post #34
invokestatic wrote: post #32

Earlier quoted context omitted.

Sorry if I misinterpreted your post but I don't think that changes my response much. You can absolutely use Win32 Forms and WPF (and probably Qt) with a game. They can be overlaid on top of a DirectX or OpenGL window (with a transparent background) -- I've done it before! I don't think it would have any of the downsides you mentioned, either, except that it wouldn't be GPU accelerated or actually rendered inside the…

Qt's QML uses OpenGL and can at least render into an FBO in your existing OpenGL context more or less out of the box. Integrating it with a game render loop deeper should be possible too, but more effort.

Qt is moving into a 3D API agnostic backend.
Post reply on HN