Could ImGUI Be the Future of GUIs?

Post by pjmlp » Sun, Apr 28, 2019, 6:47 AM UTC

invokestatic wrote: post #32

781 wrote: post #24

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…

Post by geezerjay » Sun, Apr 28, 2019, 7:06 AM UTC

josephg wrote: post #37

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…

On the allocation point, the efficient way to handle this is to use a per-frame memory pool. Because nothing in the IMGUI can persist between frames, you can allocate a single arena of memory for any UI elements that need to store bounding boxes or callbacks or whatever. Each frame just reset your next_ptr to the start of the arena. Technically you are allocating memory, but in practice your allocations are free.

Post by scotty79 » Sun, Apr 28, 2019, 7:25 AM UTC

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…

Post by scotty79 » Sun, Apr 28, 2019, 7:54 AM UTC

jbverschoor wrote: post #14

Can we please just stop moving around in circles in the tech industry? Nobody seems to learn anything from past methods, tech and everything.

Post by loup-vaillant » Sun, Apr 28, 2019, 8:18 AM UTC

geezerjay wrote: post #83

josephg wrote: post #37

Earlier quoted context omitted.

On the allocation point, the efficient way to handle this is to use a per-frame memory pool. Because nothing in the IMGUI can persist between frames, you can allocate a single arena of memory for any UI elements that need to store bounding boxes or callbacks or whatever. Each frame just reset your next_ptr to the start of the arena. Technically you are allocating memory, but in practice your allocations are free.

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.

  // 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);