4 ms·

> Nowadays I am starting to believe that the term has caused more harm than benefits, because it suggests there are two camps "IMGUI" vs "RMGUI". The reality is

by d--b 2y ago

> Nowadays I am starting to believe that the term has caused more harm than benefits, because it suggests there are two camps "IMGUI" vs "RMGUI". The reality is there is a continuum of possibilities over multiple unrelated axises. > The fact that we are even trying to put an official definition to a label is hindering people's imagination about the many possible areas of researches to be done in UI space. Well said, but then the author proceeds and lists what IMGUI is and what it’s not. My opinion is that we may just think about IMGUI as “the stuff that dear-imgui does”, which people understand well. And yes there’s a loop, and things get redrawn all the time and so on. Everything else that borrows concepts from that is IMGUI-ish. I for myself definitely use some IMGUI concept when I do js apps, but is it imgui? Definitely not. Is it imgui-ish, hell yeah. Trying to make the term IMGUI mean “good way of doing UI” is not gonna work…

torlok 2y ago
It sucks that this is what immediate mode got reduced to. If you listen to what Casey was advocating for, it was to avoid the need to synchronise state between local state and black box state. This can be applied to UI, but just as well to f.e. a physics engine, where a constraint can live as long as you keep calling doConstraint(). Unfortunately, all people seem to have gotten out of that was if(doButton(...)).
theamk 2y ago
There maybe a continium in games space, but in non-game apps it's all crystal clear and sharp boundaries: Can the app stop generating wakeup interrupts and let CPU/GPU sleep? Yes -> this means app events (like network transfer) need to be able to generate "update" events, which means those events need to be directed somewhere, which means retained mode. No -> this means GUI is allowed to poll non-stop and thus can check every variable 60 times per second to support immediate mode.
- modeless 2y ago
  Immediate mode and polling are not the same thing. With Dear ImGui you own the event loop so you can draw as frequently or infrequently as you want. It is not necessary to draw 60 times per second when nothing is happening. Dear ImGui's sample code currently does draw every frame even when nothing is happening. Omar has said that he would eventually like to change this and it's on his roadmap, but it's low priority because he is currently targeting game industry users and doesn't want to attract a lot more users in other areas that will add to his support load and dilute his focus. [1] He also has said the same thing about accessibility and fancy theming. These features are good examples of why "the stuff that dear-imgui does" is not a good definition of immediate mode. People often assume that anything Dear Imgui doesn't do is hard or impossible for any immediate mode API, but that's far from the truth. Omar is only one guy. He has a target audience in mind and is not trying to satisfy all use cases at once. You have to remember that when comparing Dear ImGui to a framework like Qt or SwiftUI or whatever that has hundreds if not thousands of developers contributing to it. [1] https://github.com/ocornut/imgui/issues/7892 https://github.com/ocornut/imgui/issues/7892

by d--b 2y ago

torlok 2y ago

It sucks that this is what immediate mode got reduced to. If you listen to what Casey was advocating for, it was to avoid the need to synchronise state between local state and black box state. This can be applied to UI, but just as well to f.e. a physics engine, where a constraint can live as long as you keep calling doConstraint(). Unfortunately, all people seem to have gotten out of that was if(doButton(...)).

theamk 2y ago

There maybe a continium in games space, but in non-game apps it's all crystal clear and sharp boundaries: Can the app stop generating wakeup interrupts and let CPU/GPU sleep? Yes -> this means app events (like network transfer) need to be able to generate "update" events, which means those events need to be directed somewhere, which means retained mode. No -> this means GUI is allowed to poll non-stop and thus can check every variable 60 times per second to support immediate mode.

modeless 2y ago
Immediate mode and polling are not the same thing. With Dear ImGui you own the event loop so you can draw as frequently or infrequently as you want. It is not necessary to draw 60 times per second when nothing is happening. Dear ImGui's sample code currently does draw every frame even when nothing is happening. Omar has said that he would eventually like to change this and it's on his roadmap, but it's low priority because he is currently targeting game industry users and doesn't want to attract a lot more users in other areas that will add to his support load and dilute his focus. [1] He also has said the same thing about accessibility and fancy theming. These features are good examples of why "the stuff that dear-imgui does" is not a good definition of immediate mode. People often assume that anything Dear Imgui doesn't do is hard or impossible for any immediate mode API, but that's far from the truth. Omar is only one guy. He has a target audience in mind and is not trying to satisfy all use cases at once. You have to remember that when comparing Dear ImGui to a framework like Qt or SwiftUI or whatever that has hundreds if not thousands of developers contributing to it. [1] https://github.com/ocornut/imgui/issues/7892 https://github.com/ocornut/imgui/issues/7892