I am looking for similar syntax like egui, is immediate graphics but with caching and functions like retained graphics and uses similar system resources as pure retained graphics.
I just want to write simple gui applications with simple buttons and dropdowns that is it. I have used egui and that uses about 1-2% on idle whereas fltk-rs uses 0%, even when clicking on buttons and stuff.
Is this any different than Is there a similar gui library to egui but it is retained? ?
If you read my post yes it is different I am asking something different
The difference between the two is almost certainly not caching. Rather eframe runs your main function every frame while fltk-rs only runs it whenever an event is received. It is possible to run egui with a custom adapter that behaves the same as fltk-rs, but I'm not sure eframe itself support this. Caching can only reduce idle consumption, not bring it down to the 0% you are observing for fltk-rs. Only blocking until there is an incoming event can do that.
Note that if there's no repaint request or interaction egui won't re-run the main function. The catch however is that moving the mouse pointer does count as an "interaction" (due to hover effects), so that will cause the main function to re-run when it might not matter.
The egui demo backend panel gives good example of controlling continuous repaint or how to set repaint rate.
Egui is for game development, where there's extensive compute for each frame and the application that's on top uses most of the machine.
Egui is mostly used for 3D graphics programs, where most of the time is going into 3D work, with Egui just putting on a 2D overlay with menus and such. So it may not be a good choice for programs that spend much of their time idle.
There is a mechanism in winit to slow the frame rate way down when its window is minimized. You could code the event loop so that loss of focus also slows down the frame refresh rate. Drop from 60 FPS to 6 FPS or 3 FPS when the user isn't interacting with the program.
In fact, you're not obligated to redraw on every possible frame. You can set up your event loop to only redraw on events.
I strongly disagree that egui is primarily for games [1] and the implication that you must have extensive compute to use it. The leading counter example is the web browser: a super massive application that literally runs in the palm of your hand. Egui has been shown to run on resource-constrained devices like e-ink readers, and there are some efforts to modernize it.
Additionally, some conservative measurements indicate that egui performs very well in practice.
The "just don't render every frame" trope is misguided. Egui has a lot of animations by default that will cause redraws beyond just interacting with the GUI. Some of these UI animations can be disabled. But some are controlled by the application (especially animated GIFs and videos) and will always redraw. This is also not much of a concern, because drawing the GUI is cheap compared to decoding video. The heaviest parts of drawing are already cached, like text layout.
It is possible to make it not redraw at all unless it's absolutely necessary. Even 3 or 6 fps is overkill if it draws exactly the same frame (and remember the e-ink port, those things take multiple seconds to refresh the screen once). The problem is that there is no one-size-fits-all solution. I think egui strikes a good default balance between low resource usage and nice/shiny things. And I also think it is customizable enough to send it more extremely in either direction.
The egui showcase has few games and a LOT of apps. âŠī¸
Yep. servo uses egui.