51–60 of 128 posts
GUIs are multi-process, multi-system, multi-clock, multi-network entities, or at least they have the potential to be. Immediate Mode GUIs are almost non-scalable by design.
Imagine a multi-system asynchronous AR collaboration environment. Now imagine that as an Immediate Mode GUI. If we had enough horsepower to do that, we'd be doing something far better with it.
Earlier quoted context omitted.
I didn't say that it's not possible to solve these problems in a retained GUI, just that existing ones, QT, Win32, WPF have these problems. And since writing a full retained GUI is not exactly trivial, people just wrote mini-GUIs using immediate mode. When I talked about retained mode APIs, I was thinking about scene graphs, where you say "addMesh" or "addSphere" and then just call "renderFrame". I'm aware that most…
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…
> ... 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…
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…
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?
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?
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 renderer: they get re-rendered every frame for you. Componentes normally have events and state by themselves. Sometimes there's a visual editor too.
The main difference is the API. One is lower level than the other. In practice, the APIs aren't that different, except when it comes to event handling.
FWIW, Unity are moving away from ImGUI (to a classic retained mode UI system) https://blogs.unity3d.com/2019/04/23/whats-new-with-uielemen...
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?
An immediate mode GUI is defined by writing an update function that draws the UI, passing in data and conditionally running callbacks for interactive elements like buttons. There is no model saved in memory, rather the structure of the UI is implied through the code path taken by the update function. The UI library uses this function to both draw the UI and handle user interactions.