[overgard]

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 well. Also... Look there's like a million downsides.

Also saying there's no memory allocation is really misleading. There's PLENTY of memory allocation, per frame, you're just not explicitly doing it yourself. It's actually much worse than an RMGUI in this regard, because at least with an RMGUI you get the allocations over with once. With an IMGUI you're allocating things all the time. They're probably much smaller allocations, but lots of small allocations does not make for good performance.

One final note, the Unity 3D example always gets used. If you've ever written a plugin for unity or a custom editor, you're very familiar with the fact that it's editor gui system is extremely limiting and kind of sucks. I mean, it's an example, but once you're past the basics it's kind of a bad example.

[josephg]

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.

[geezerjay]

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.

[loup-vaillant]

Arenas are the simplest allocation scheme ever.

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

By the way, such "separate complex ad hoc" memory allocation schemes are the reason why manual memory management is faster than garbage collection. If you did everything with malloc(), it would be slower (unless the GC language allocates much more than C, which they often do).

[Keyframe]

No need to malloc each frame. Malloc at startup and memset each frame (don't even need to do that, tbh).

[maccard]

Nope, just set the pointer back to where it started from. You do need to be super careful doing this though, as anything that relies on RAII (in c++ land) will be busted. You could manually call the destructor on the object in that case, but kind of defeats the purpose of the "no allocation" goals

[geezerjay]

C++ includes it's "placement new" feature specifically to cater to the memory pool needs. There's no allocation, and only constructor and destructor calls.

[tom_]

It’s a good idea to have a mode that does malloc every frame, as that makes stale pointers much easier to find.

[brann0]

A memory arena that is reset every render loop is the simplest memory allocation possible.

[sly010]

Where do you store pointers to textures? Or do you upload textured to the GPU every frame? What about scroll positions an other non application state?

[learc83]

Unity 2019.1 has a new retained mode GUI system for editor UI.

[kuzehanka]

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.

[learc83]

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

[forrestthewoods]

Whoa there.

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

[jrk]

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.)

[forrestthewoods]

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.

[overgard]

Weirdly, when Unity was first starting out it had this "UnityScript" thing, which was javascript-but-not-quite. Luckily it's mostly been phased out (I don't think newer versions even support it)