Add Continuous mode to ctx.memory.options #4214
Conversation
| let continuous_mode = egui_ctx.options(|options| options.continuous_mode); | ||
| if continuous_mode { | ||
| let viewport_id = egui_ctx.viewport_id(); | ||
| // TODO : Do not recall until the next repaint. |
There was a problem hiding this comment.
The contributing guidelines say:
Add your github handle to the TODO:s you write, e.g:
TODO(emilk): clean this up
There was a problem hiding this comment.
The contributing guidelines say:
Add your github handle to the TODO:s you write, e.g:
TODO(emilk): clean this up
thank you.
There was a problem hiding this comment.
The contributing guidelines say:
Add your github handle to the TODO:s you write, e.g:
TODO(emilk): clean this up
If you know how to pass the doc test, please let me know.
It doesn't work with the "no_run" option.
It would be better to exclude what is in egui_demo_app because it seems that we do not want to write it in the doc.
Still, I'd like to know how.
| // TODO(rustbasic) : Do not recall until the next repaint. | ||
| // 1000 millis / 60 fps = 16.67 millis | ||
| self.egui_ctx | ||
| .request_repaint_after_for(std::time::Duration::from_millis(8), viewport_id); |
There was a problem hiding this comment.
why 8 ms delay?
It takes about two attempts.
It is the most efficient.
If you do 16.67ms, 60 fps cannot be achieved.
In conclusion, this method solves everything with only 1% CPU usage.
However, having subviewports increases usage by about 10%.
Currently, if you keep calling request_repaint(), more than 10% of your CPU is being used even without doing anything.
There was a problem hiding this comment.
But why not request an immediate repaint? eframe has vsync anyways
There was a problem hiding this comment.
But why not request an immediate repaint? eframe has vsync anyways
But why not request an immediate repaint? eframe has vsync anyways
This is an unnecessary waste of CPU usage.
It would be a good idea to apply this and continue to monitor and upgrade.
It can't be perfect from the beginning.
There was a problem hiding this comment.
It's not a waste of CPU, because of vsync.
There was a problem hiding this comment.
It's not a waste of CPU, because of vsync.
It will be more effective if you actually use it and check the CPU usage.
There is also the advantage that the user does not have to worry about request_repaint().
| @@ -191,6 +191,10 @@ pub struct Options { | |||
| /// Controls the tessellator. | |||
| pub tessellation_options: epaint::TessellationOptions, | |||
|
|
|||
| /// If `true`, This will call `egui::Context::request_repaint()` at the end of each frame | |||
| /// If `false` (default), egui is only updated if are input events (like mouse movements) or there are some animations in the GUI. | |||
| pub continuous_mode: bool, | |||
There was a problem hiding this comment.
Maybe we should just move enum RunMode { into egui from crates/egui_demo_app/src/backend_panel.rs. At least we should copy its documentation.
| @@ -65,10 +65,11 @@ impl BackendPanel { | |||
| match self.run_mode { | |||
There was a problem hiding this comment.
self.run_mode can be replaced with options.continuous_mode
Add Continuous mode to ctx.memory.options