5 ms·

If your entire system ran with immediate mode GUIs your performance would either be in the toilet or battery life would be destroyed (or both). They’re great f

by epcoa 3y ago

If your entire system ran with immediate mode GUIs your performance would either be in the toilet or battery life would be destroyed (or both). They’re great for games and GPU where you’re in a for a pound anyway. There are some music apps that use it and it’s horrible if you’re on a laptop. No I don’t want to consume a couple watts when I should be idling because the entire screen is being repainted doing nothing. Makes electron seem nice.

goodpaul6 3y ago
I'm not sure the perf/battery life tradeoff is a necessary aspect of immediate mode UI. while (running) { event := get_next_event() process_event(event) repaint() } You could just have get_next_event block until there is a meaningful event that occurs (e.g. mouse click). You could even have your UI report "interactive" rectangles to the event layer to prevent it from producing e.g. mouse move events that are irrelevant. IMGUI is just a different API design IMO.
- kvemkon 3y ago
  > IMGUI is just a different API design IMO. There are so many issues about so called "power saving mode" and several open PRs like https://github.com/ocornut/imgui/pull/5116 https://github.com/ocornut/imgui/pull/5116.
- n2d4 3y ago
  If you do that, you have an event loop again (like in the OP), which your comment's grandparent was trying to get rid of (and your parent explained to them why they can't).
  - whstl 3y ago
    In practice there is always a loop. I believe the point flohofwoe was making is that with an immediate UI you don't have to even touch events in your immediate UI code (they are abstracted away, if needed, in a pretty clean manner, IMO), so there's no need to do anything to get a "sane event loop". I might be wrong about what's his point though.
    - n2d4 3y ago
      There's a loop yes, but not an event loop - the other argument is that you can have a loop that runs every frame, and you just rerender the whole thing
      - whstl 3y ago
        Not really. To expand on my response: In practice there is always the operating system's event loop, both in retained and immediate mode. This is true for all mainstream operating systems.
        n2d4 3y ago
        I mean, that's just being overly pedantic. Surely you see a difference between these two pieces of code? while (true) { redraw(); } and while (true) { waitForAndProcessNextEvent(); redraw(); }
        whstl 3y ago
        Please don't call me pedantic. What I am explaining is that in practice you have to use the second code, because of how operating systems work. This can be handled by a windowing library (SDL, GLFW, Sokol), and the adapters for libraries like Dear Imgui, Nuklear, etc. also expect the second code. There are ways to skip processing events in some OSs, but this is not really advised by OS writers, and in some cases you will get subpar experience, apps that don't close correctly, etc.
- epcoa 3y ago
  > You could even have your UI report "interactive" rectangles to the event layer to prevent it from producing e.g. mouse move events that are irrelevant. And then what? With this one innocuous seeming sentence you are hand waving a way a ton of complexity. If you try to implement it you will at least have some respect for toolkit authors. > IMGUI is just a different API design IMO. Yes one that is lower level and therefore is fundamentally harder to deal with to get all the things people take for granted in a full blown mature state based GUI toolkit. You can implement a retained GUI toolkit with IMGUI. Or you can use something already done. IMGUI eschews this complexity as part of its purpose but it comes with trade offs that limit its use cases.
  - goodpaul6 3y ago
    I decided to implement it (IMGUI that only repaints when relevant interactions occur) so that my point comes across more clearly: https://github.com/goodpaul6/imgui-power-saving-example https://github.com/goodpaul6/imgui-power-saving-example Of course this is a greatly simplified example, but I can see this extending to any GUI widget that can be represented with a (hierarchy) of rectangles.
    - epcoa 3y ago
      All major GUI toolkits are ultimately implemented on some immediate mode drawing system. So I don’t see the point. (You’re literally just unfactoring what a GUI library does behind the scenes into your loop.) When you unsimplify your example then you are reinventing a wheel. A big wheel. It can be done, but it’s a lot of work. And then you might go factoring things back so it starts to look very similar to prior art. It’s actually easier than ever to implement accessibility for instance (assuming you’re ok pulling in a large dependency), but show me an actual example of this done on top of imgui. Things I never said: imgui doesn’t have uses, imgui isn’t great. But its scope is limited.
      - goodpaul6 3y ago
        Here's an IMGUI library that's also accessible (via AccessKit): https://github.com/emilk/egui https://github.com/emilk/egui
- all2 3y ago
  There's also the paradigm where only new information is painted.
forrestthewoods 3y ago
> If your entire system ran with immediate mode GUIs your performance would either be in the toilet or battery life would be destroyed (or both). You might be surprised! Modern computers are unbelievable fast.
- LtWorf 3y ago
  Try to mine bitcoins on battery and let me know how much it lasts. Same thing.
  - forrestthewoods 3y ago
    … huh? The entire purpose of Bitcoin mining is to use every compute cycle. My entire point about about ImGui is it doesn’t take as many cycles as people seem to think.
suby 3y ago
It doesn't need to be inefficient, it depends on the implementation. Immediate mode is describing the API and usage, you can implement it such that it's retained mode behind the scenes, or only redrawing when necessary, etc. I've written an immediate mode GUI for my projects and it's fine for performance. I've written a music player for instance which uses a negligible amount of CPU, it uses slightly more resources than Clementine, my previous music player.
- epcoa 3y ago
  > that it's retained mode behind the scenes, or only redrawing when necessary And why reinvent that wheel? Then localization and accessibility while you’re at it? > it uses slightly more resources than Clementine That’s an odd flex, Clementine is extremely horrible for CPU usage (compared to nicer looking examples), probably not due to the GUI, but still. foobar2000 with a ton of plugins works better in wine.
  - deleted 3y ago
    [deleted]

by epcoa 3y ago

goodpaul6 3y ago

I'm not sure the perf/battery life tradeoff is a necessary aspect of immediate mode UI. while (running) { event := get_next_event() process_event(event) repaint() } You could just have get_next_event block until there is a meaningful event that occurs (e.g. mouse click). You could even have your UI report "interactive" rectangles to the event layer to prevent it from producing e.g. mouse move events that are irrelevant. IMGUI is just a different API design IMO.

kvemkon 3y ago
> IMGUI is just a different API design IMO. There are so many issues about so called "power saving mode" and several open PRs like https://github.com/ocornut/imgui/pull/5116 https://github.com/ocornut/imgui/pull/5116.
n2d4 3y ago
If you do that, you have an event loop again (like in the OP), which your comment's grandparent was trying to get rid of (and your parent explained to them why they can't).
- whstl 3y ago
  In practice there is always a loop. I believe the point flohofwoe was making is that with an immediate UI you don't have to even touch events in your immediate UI code (they are abstracted away, if needed, in a pretty clean manner, IMO), so there's no need to do anything to get a "sane event loop". I might be wrong about what's his point though.
  - n2d4 3y ago
    There's a loop yes, but not an event loop - the other argument is that you can have a loop that runs every frame, and you just rerender the whole thing
    - whstl 3y ago
      Not really. To expand on my response: In practice there is always the operating system's event loop, both in retained and immediate mode. This is true for all mainstream operating systems.
      - n2d4 3y ago
        I mean, that's just being overly pedantic. Surely you see a difference between these two pieces of code? while (true) { redraw(); } and while (true) { waitForAndProcessNextEvent(); redraw(); }
        whstl 3y ago
        Please don't call me pedantic. What I am explaining is that in practice you have to use the second code, because of how operating systems work. This can be handled by a windowing library (SDL, GLFW, Sokol), and the adapters for libraries like Dear Imgui, Nuklear, etc. also expect the second code. There are ways to skip processing events in some OSs, but this is not really advised by OS writers, and in some cases you will get subpar experience, apps that don't close correctly, etc.
epcoa 3y ago
> You could even have your UI report "interactive" rectangles to the event layer to prevent it from producing e.g. mouse move events that are irrelevant. And then what? With this one innocuous seeming sentence you are hand waving a way a ton of complexity. If you try to implement it you will at least have some respect for toolkit authors. > IMGUI is just a different API design IMO. Yes one that is lower level and therefore is fundamentally harder to deal with to get all the things people take for granted in a full blown mature state based GUI toolkit. You can implement a retained GUI toolkit with IMGUI. Or you can use something already done. IMGUI eschews this complexity as part of its purpose but it comes with trade offs that limit its use cases.
- goodpaul6 3y ago
  I decided to implement it (IMGUI that only repaints when relevant interactions occur) so that my point comes across more clearly: https://github.com/goodpaul6/imgui-power-saving-example https://github.com/goodpaul6/imgui-power-saving-example Of course this is a greatly simplified example, but I can see this extending to any GUI widget that can be represented with a (hierarchy) of rectangles.
  - epcoa 3y ago
    All major GUI toolkits are ultimately implemented on some immediate mode drawing system. So I don’t see the point. (You’re literally just unfactoring what a GUI library does behind the scenes into your loop.) When you unsimplify your example then you are reinventing a wheel. A big wheel. It can be done, but it’s a lot of work. And then you might go factoring things back so it starts to look very similar to prior art. It’s actually easier than ever to implement accessibility for instance (assuming you’re ok pulling in a large dependency), but show me an actual example of this done on top of imgui. Things I never said: imgui doesn’t have uses, imgui isn’t great. But its scope is limited.
    - goodpaul6 3y ago
      Here's an IMGUI library that's also accessible (via AccessKit): https://github.com/emilk/egui https://github.com/emilk/egui
all2 3y ago
There's also the paradigm where only new information is painted.

forrestthewoods 3y ago

> If your entire system ran with immediate mode GUIs your performance would either be in the toilet or battery life would be destroyed (or both). You might be surprised! Modern computers are unbelievable fast.

LtWorf 3y ago
Try to mine bitcoins on battery and let me know how much it lasts. Same thing.
- forrestthewoods 3y ago
  … huh? The entire purpose of Bitcoin mining is to use every compute cycle. My entire point about about ImGui is it doesn’t take as many cycles as people seem to think.

suby 3y ago

It doesn't need to be inefficient, it depends on the implementation. Immediate mode is describing the API and usage, you can implement it such that it's retained mode behind the scenes, or only redrawing when necessary, etc. I've written an immediate mode GUI for my projects and it's fine for performance. I've written a music player for instance which uses a negligible amount of CPU, it uses slightly more resources than Clementine, my previous music player.

epcoa 3y ago
> that it's retained mode behind the scenes, or only redrawing when necessary And why reinvent that wheel? Then localization and accessibility while you’re at it? > it uses slightly more resources than Clementine That’s an odd flex, Clementine is extremely horrible for CPU usage (compared to nicer looking examples), probably not due to the GUI, but still. foobar2000 with a ton of plugins works better in wine.
- deleted 3y ago
  [deleted]