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

91–100 of 128 posts

Re: Could ImGUI Be the Future of GUIs?

#91

Post by weinzierl »

overgard wrote: post #29
weinzierl wrote: post #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 th…

Immediate mode, if anything, makes this harder. (You absolutely have to run the GUI on one thread, for instance). Really though you can get around that on either of them by spawning a worker thread/coroutine/etc. on button clicks and so on.

The real problems start, when the worker thread needs to update the GUI, for example to advance a progress bar. With the frameworks I know I have to build a communication channel between the threads and tell the GUI thread to show and update the progress bar.

My hope was that with an immediate mode framework I could just show a progress bar on top of the existing GUI right from the worker thread. I don't know enough about immediate mode to say if this is really possible. It would simplify a lot of my code though.

Re: Could ImGUI Be the Future of GUIs?

#92

Post by gmueckl »

benj111 wrote: post #86
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…

>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 the best gaming rigs with either sound or graphics alone.

Bottom line: the need to optimize always comes sooner than you would expect.

Re: Could ImGUI Be the Future of GUIs?

#94

Post by hevi_jos »

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…

If you have to create a big texture for the GPU, this is the definition of slow.

One of the big advantages of drawing for every frame is that you only need to draw what is visible. And do it in real time, with no perceived lag.

For a text editor I use I only draw at any given time 1/10.000 of what is actually there. In fact, you don't need to draw textures at all with the GPU, Apple or Microsoft or Google does not do that for drawing text because it is extremely slow generating this texture and it is not flexible.

Those companies in the bleeding edge, they draw directly in the screen from curves like bezier approximations.

Re: Could ImGUI Be the Future of GUIs?

#95

Post by laythea »

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 data binding. As the control is passed a pointer to the actual memory for he value, it can "go get it" when rendering, rather than my application setting its state. - I still have classes to represent elements and state, so its conceptually simple to build controls on controls. I found this difficult with Imgui.

Cons: - renders 100% full speed, but I am working on way to speed up and slow down render loop depending on user activity, so that when sitting idle, the cpu is not burning.

Re: Could ImGUI Be the Future of GUIs?

#96

Post by polytronic »

The single most important factor when it comes to UI is text rendering. Immediate mode UIs are based on text rasterization, ie polygon creation for each character of the text while retained mode text is usually featuring texture atlases containing all characters in upper and lower case. This of course introduces a limitation on the number of fonts available to the developer, font sizes, etc. My 3D engine is using an immediate mode UI for the editor and tools while it allows for creation of retained mode UI for in-game UI components by automatically generating texture atlases for the selected font types

Re: Could ImGUI Be the Future of GUIs?

#97

Post by Larowyn »

amluto wrote: post #50

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…

That's not how it would go, you don't need state to handle different events, in the case you describe the button is not clicked, of course the button would not trigger on anything else than a mouseup that would be incredibly dumb. It will go something like this: - The mouse is on top of the button, you could render your button differently with that information. - The mousdown event trigger on top of the button again you can do something to make the button render differently. - If the mouseup event occur the button trigger. Instead of keeping a state on your button you render your uis elements conditionned on the cursor position and state of the mouse (up or down)

Re: Could ImGUI Be the Future of GUIs?

#98

Post by gmueckl »

charlesetc wrote: post #10
seanalltogether wrote: post #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…

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.

It depends on the probkem younare trying to solve with your GUI, I suppose. Sometimes, it is better to just recreate the whole GUI to adapt to a model change (e.g. the user moved half of the tree nodes somewhere else), sometimes it is easier/faster/... to just update the existing GUI (e.g. update the text of a label inside a complex dialog widget).

Re: Could ImGUI Be the Future of GUIs?

#99

Post by hevi_jos »

nh2 wrote: post #47
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 significan…

Following the same logic that you use... have you calculated how much memory do you need to store the memory of a single treeview, or a single scrolling document of just several pages?

Two floats? You are using a memory that is a CPU memory, a big chunk of memory. That does not exist in the GPU. In the GPU the memory is distributed so it can be used in parallel.

Immediate GUI exist because of GPUs, because with GPUs you can draw frames fast. If you look at Imgui code it uses GPU drawing for everything. In fact it uses only two drawing functions copying small rectangles in the screen.

It is drawing a single big chunk of memory what is extremely slow, and you need to do that before you do offsetting.

And if you work with variable data, like a treeview, you need to allocate for a finite amount of memory in the GPU buffers.

Re: Could ImGUI Be the Future of GUIs?

#100

Post by hevi_jos »

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?

It comes from 3D gaming and hardware acceleration.

In 3D you use hardware acceleration that is 100-200 times more energy efficient than drawing in the CPU. But you loose flexibility.

It is actually way cheaper to actually clear the screen and redraw it again each 1/60 of a second than to complicate the design of the drawing.

If you make it complex, the GPU could not draw it, because the GPU is not flexible, so only the CPU could draw it.

With GPUs, those tricks do not make sense at all.

In the past, there was a lot of optimization for things like drawing windows on the screen, things like circular buffers, "happy ideas" everywhere that made it efficient in the CPU at the expense of complexity, that the CPU could handle.

Imagine solving a mathematical equation. With matrices we fill a table with zeros that represents the elements of the table that do not exist. This is inefficient, but with a matrix a machine can solve it automatically without "thinking".

Immediate Gui uses the same concept, it draws without caring for last frames or states, making it way simpler.

Post reply on HN