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

[epcoa]

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

Once again, all major GUI toolkits and browser are implemented on top of immediate mode graphics APIs, so you continue to beat this straw man argument. Obviously everything is ultimately immediate mode. No one was refuting those points and sorry they’re not particularly informative.

The point is you’re just rearranging where that state lives and who manages it. You’re retaining it somewhere. But your app is not the best place to manage a lot of this state (as even egui itself admits), it belongs in a well tested library.

Once you start using dirty rectangles, someone has to keep track of them. What benefit is it to me to drive when to call the apis for those details?

IMGUI has a certain elegance where your answer to that is to just say fuck it, and that works well for like a game editor. (The point about accessibility was not that it can’t be done but IMGUI rarely gets actually used where this is ever done). Because if your answer isn’t fuck it to all those things than just go get a library to it for you, which will be managing that state.

I think a lot of people pining for IMGUI really just want sane data binding. Which is understandable, but IMGUI is often throwing the baby out with the bath water.

Like honestly read that egui advantages/disadvantages. That’s a lot of cons (that first one woo) for that one pro (which is not even inherent to all retained APIs).