Well I guess your book needs a new edition. The type of gui you're referencing is typically referred to as a retained mode gui.

The point is, I don't want people to see "GUI library" and think it's okay to use this for your random phase-of-the moon application that has no good reason to redraw at 2400 fps or whatever the enthusiasts want these days.

Just click on the link and you can easily see it only redraws when something on the screen changes. It's amazing how quickly people will dismiss something these days based on their own made up reasons.

The poster above me explained to me that it's not like that?

Click the link, open the backend tab, and look where it says "Only running UI code when there are animations or input."

Then you won't have to waste cycles deciding which random internet comment from a stranger to believe

If you set up "winit" so it only redraws on events, then you don't trigger an EGUI redraw very often. But if updates that affect the EGUI items are coming in from another source, like the network, you have to explicitly trigger a winit redraw cycle.

Don't know about web. Seems overkill if all you have are GUI widgets. Egui is most useful on top of something more graphical.

Scrolling text is a problem. EGUI isn't good at big text boxes with much offscreen text. That can be worked around.

If it’s used as a game ui, games typically render everything at 60fps - so the energy cost from ui layer would be neglible.

Afaik nobody is forcing to rerender the ui layer if nothing changes, though. Just render it to a texture and compose … no need to put everything to the same render target?

It has this claim:

"egui is not a framework. egui is a library you call into, not an environment you program for."

So I suspect it gives you control on when to redraw and you might eg call it only when user input happens in your app or there's a some other state change that changes what is shown.