by tokyodude on 4/25/19, 7:27 AM with 124 comments
by overgard on 4/27/19, 11:36 PM
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.
by yonilevy on 4/27/19, 10:28 PM
by theclaw on 4/27/19, 11:14 PM
It works very well in the context where you already have fast graphics and an update loop, and you're already expecting to redraw the whole screen every frame. It does not really suit more complex, text-heavy UIs where you're rendering thousands of glyphs with proper kerning and ligatures and anti-aliasing, etc, and want the result of that hard work to be retained in the framebuffer unless it absolutely needs to change.
by pciexpgpu on 4/27/19, 11:26 PM
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 will fall over. Infact, that's why we have every major browser move their touch and animation systems into a layer based compositor system (into a separate thread / process).
The author also grossly misses their own example of 'how a spreadsheet with many rows and columns will update faster using ImgUI' and how Instagram styled apps will fare better ImgUi.
A retained mode renderer will use virtual scrollers, efficient culling of nodes for both display and hit-testing (scale to billions of virtual cells) and more importantly help a team of people coordinate their work and get things done.
We are no longer in the 90s.
by mooman219 on 4/27/19, 11:02 PM
by seanalltogether on 4/27/19, 10:39 PM
Immediate vs retained is a simple case of budgeting against cpu usage or memory usage, and it should be considered in that light. (immediate uses more processing, retained uses more memory)
by geekpowa on 4/27/19, 11:27 PM
Many of authors most significant criticisms on retained GUIs are implementation considerations. GUI frameworks exist that solve his key criticisms of complexity and are pleasant to work with.
Criticisms that target core architecture of retained GUI I don't consider to be valuable design goals, at least in settings where I work on GUIs. e.g. memory usage.
Alot of things are glossed over that remain challenges in both, e.g. layout management.
HTML is an interesting example. First iteration of HTML was essentially immediate mode if you think about a single client/server interaction as a GUI update cycle. Server sends draws to client browser and client browser sends back to server user selections. There is no retained state on gui side. Now with programmatic access to DOM, ability to attach events to DOM elements from client side it is now a retained GUI. Seems to be where things evolve to naturally.
The GUI framework I use nearly daily is retained and very pleasant to work with in terms of ease of belting out screens & readability/maintainability of code. The simplicity comes with compromises though as there are limits on GUI idioms that can be expressed. Occasionally run into those boundaries and resulting GUI does look a little plain and unexciting, but for something that is substantially about data entry its fine.
by arianvanp on 4/27/19, 11:10 PM
The idea is that a button is a UI element that _blocks_ until an event is fired. You can then compose elements in time like:
button "hey" >> label "clicked"
Or you can compose programs in space:
(button "hey" <> label "not clicked")
Now, by combining both space and time, we can create a program that changes the label when clicking as follows:
program = (button "toggle" <> label "off") >> (button "toggle" <> label "on") >> program
by RandyRanderson on 4/27/19, 11:22 PM
As the author points out, HTML has a poor design (eg. if you want to have a 1000x1000 cell table, you have to have 10^6 actual cells - that's a lot of tds or whatever to parse).
Modern OO GUI frameworks don't do this - they say something like:
cellRenderer.draw(target, row,col,position,size)
No creation of objects required. Of course since it's so easy to create OO programs a lot of code isn't great... and then others copy that code and so it goes.
Seems like we keep re-creating software b/c we haven't taken the time to look at what exists and only then decide on what to keep and what to change. "This is too complex - I'll re-write it!". 10 years later: "We added all the features that the existing software had and now the new one... is just as slow... but we did sell a lot of conference tickets and books so... totally worth it."
When I was 20 I also thought I knew better so I get it.
by babel_ on 4/27/19, 11:57 PM
A balance may be letting people define it either way, so that manually written ui still can have auto-layout yet intuitive code (following control flow primitives), whilst allowing generated retained uis to be manually editable -- perhaps even allowing one to then embed one within the other, a boon for scripted interfaces that perhaps have people of various levels of experience producing ui elements, such as a musician with little experience being able to add a simple visualiser in an immediate manner to a deeply retained daw gui.
Of course, there's a lot here that is implementation, and some criticism either way can be optimised out. Immediate mode can still cache its rendering, we've had optimised blitting since the early days, and is only usually a problem with complex ui. Retained would get fewer cache misses if we weren't allocating madly across the heap and took a more disciplined approach allocating to contiguous memory -- which is almost entirely a language/api problem (in my experience) that can also happen with immediate but we typically don't see since it's often done in a more procedural style that is allocating to some pool.
Other api elements, such as handling lists etc aren't really a differentiation between retained and immediate, those can be made in either.
For me, I often find that the ability to write out prototype ui code in an immediate style in very quick and satisfying (exactly what I want in prototyping), however once I start to expand upon a ui, I find it best to over time refactor towards a retained style, since by then I will typically have some templates for what ui elements look like, and so I just have to pass a string and function pointer to fill in the template.
Can't see why we can't have nice things and let both coexist...
by pedrocr on 4/27/19, 11:22 PM
by thrax on 4/28/19, 7:14 AM
by seanmcdirmid on 4/28/19, 12:35 AM
by weinzierl on 4/27/19, 11:01 PM
> 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 thread and the consequential synchronization complications. I don't know if this is an inherent problem of retained mode GUI frameworks and if there are some that don't force all widgets into a single thread. If not, this alone is a reason to for me to find immediate mode interesting.
by Klonoar on 4/27/19, 11:03 PM
We moved away from WM_PAINT for a reason.
by amluto on 4/28/19, 2:01 AM
if (ImGUI::Button("Click Me")) {
IWasClickedSoDoSomething();
}
by jbverschoor on 4/27/19, 11:10 PM
by jayd16 on 4/27/19, 11:19 PM
by laythea on 4/28/19, 10:01 AM
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.
by sago on 4/28/19, 11:39 AM
Sometimes you need to traverse the hierarchy to figure out where things will be placed. Before traversing it for render. If your hierarchy is implicit in a call graph, you have to either duplicate your calls, or implement some kind of backend retained system so you can defer rendering until after layout.
Beyond the absolute simplest of toy UIs, immediate mode doesn't work in my opinion.
by golergka on 4/28/19, 11:54 AM
As a Unity developer, I love immediate mode GUI for debugging. But I would never in my right mind attempt to use it for actual in-game GUI. Project I'm working on right now is not incredibly complicated, it's just a typical mobile match3 game. But a typical screen here has: (1) background that has to be scaled over all screen, eveloping it around while keeping aspect ratio, (2) frame that has to be scaled to screen without keeping aspect ratio, (3) a "window" background that has to be scaled somewhat to screen (with margin), being enveloped by it, (4) interactive elements, that have to be scaled down from the "safe area" (so that there are no button under the iPhone bevel), (5) match3 game field that has to be scaled according to physical sizes of the screen, (6) pixel-perfect elements that have to be chosen according to pixel size of the screen (1x, 2x and 3x options) and scaled appropriately.
So, no, immediate GUI is definitely not the solution here.
by ahaferburg on 4/28/19, 1:05 PM
> Designed for developers and content-creators, not the typical end-user! Some of the weaknesses includes:
> - Doesn't look fancy, doesn't animate.
> - Limited layout features, intricate layouts are typically crafted in code.
It may not replace retained mode GUI toolkits, but it can certainly make the life of devs easier. If all you need is to quickly hack together an internal tool, or some quick debugging interface, keep ImGui in mind.
by zzo38computer on 4/27/19, 11:44 PM
by 4thaccount on 4/27/19, 11:58 PM
I believe Rebol's GUI support is even easier to use than ImGUI, but of course it can't be embedded and used in the same way as ImGUI either. I wonder if non Red projects could possibly hook into Red's system once Red/System gets closer to C level performance?
by nh2 on 4/28/19, 1:52 AM
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 to recreate the texture every frame, instead of once for multiple frames. So "It might use more CPU" is quite certainly true.
by 627467 on 4/28/19, 1:37 AM
by dang on 4/28/19, 12:19 AM
by dwrodri on 4/27/19, 10:16 PM
by cotelletta on 4/28/19, 8:14 AM
by polytronic on 4/28/19, 10:02 AM
by etaioinshrdlu on 4/28/19, 2:23 AM
by Vanit on 4/28/19, 4:20 AM
by abledon on 4/28/19, 12:42 AM
by grifball on 4/28/19, 5:43 PM
by qwerty456127 on 4/28/19, 4:19 AM
by pjmlp on 4/28/19, 6:37 AM
That is how we used to do it on 8 bit and 16 bit platforms, before frameworks like Turbo Vision, GEM and Workbench came into the scene.
by rambojazz on 4/28/19, 6:44 AM
by dzonga on 4/28/19, 1:49 AM
by ianrathbone on 4/28/19, 9:22 AM
by 781 on 4/27/19, 10:58 PM
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 are severely CPU bound.
A retained mode GUI is typically easier to use, convenience is not why people use immediate mode GUIs.
It's worth pointing out that the immediate/retained split doesn't apply only to the GUI - there are retained mode graphical APIs - DirectX used to have one. They are only used in low-demand games, they sacrifice a lot of speed for the convenience of using a retained mode.
by layoutIfNeeded on 4/27/19, 10:28 PM
by chaboud on 4/28/19, 2:18 AM
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.