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