[goodpaul6]

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.

[epcoa]

> 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]

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

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]

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]

Here's an IMGUI library that's also accessible (via AccessKit): https://github.com/emilk/egui

[epcoa]

https://github.com/emilk/egui#cpu-usage

Fantastic - “only” 1 to 2 ms (and that’s for simple stuff). Depending on what you’re doing that’s a big chunk. Also time you could be sleeping. Also something you don’t usually have to worry about.

[goodpaul6]

It looks like they only repaint when there is interaction as well (so it does sleep while nothing is happening).

However, my point with linking this library was just to demonstrate that accessibility and IMGUI are not inherently incompatible.

My point with the example I created above was that you don't have to trade away battery life in order to take advantage of the IMGUI paradigm. My secondary point was also to implement the "interactive rectangles" optimization I mentioned above (which only took a few lines of code).

While I agree with you that there are definitely tradeoffs, I don't think the aforementioned ones are necessary.

[kvemkon]

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

[all2]

There's also the paradigm where only new information is painted.

[n2d4]

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]

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]

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]

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]

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]

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.