-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
eframe: Graphical glitches when window has been minimized #3321
Comments
Dear emilk, I've been working for over 6 months to reproduce the issue of graphics breaking every few hours in a Windows program using the egui library. Through these efforts, I've roughly identified the reason and found a temporary way to prevent it. When the program is minimized, the value of ui.available_height() decreases. In the minimized state, the value of ui.available_height() seems to range between 0.0 to 20.0, depending on where the program was launched. I tried using the method if ui.available_height() < 100.0 { return; }, but graphics still broke every few hours when restoring from a minimized state. So,
I created the ui_available_height value using the above method and used it, but still, the graphics broke every few hours after restoring from a minimized state. Lastly, I found a method where graphics didn't break for 2-3 days upon testing. fn update(&mut self, ctx: &egui::Context, frame: &mut eframe::Frame) {
...
let mut minimized_stop_work = false;
...
egui::CentralPanel::default().frame(panel_frame).show(ctx, |ui| {
let ui_available_height = ui.available_height();
if ui_available_height < 100.0 {
minimized_stop_work = true;
}
...
}); // CentralPanel()
...
if !minimized_stop_work {
ctx.request_repaint();
}
} // fn update() By assuming that it's in a minimized state when ui.available_height() is below 100.0, and by not executing ctx.request_repaint(); (RunMode::Continuous mode in egui_demo_app.exe), the screen doesn't break even when restoring from a minimized state in Windows for a prolonged period. I've successfully tested this for 2-3 days. This method might temporarily prevent the screen from breaking. However, I'm looking forward to a fundamental solution provided by the egui library. Thanks, emilk. |
Thanks for your investigation! First of all: your posts are easier to read if you add proper markdown code blocks. You should be able to read the minimized state with The question is what We should also consider splitting |
Dear emilk, In egui v0.22.0, the value of Frame.info().window_info.minimized seems to be inconsistent, making it unusable.
Using this approach, I haven't experienced any screen corruption for several days. Thanks emilk. |
Dear emilk, I would like to share the results of using egui v0.24.0 ( & v024.1 ) on Windows for the past few days. In versions prior to egui v0.23.0, the screen often remained in a broken state. I would like to determine if the window is in a minimized state using the winapi::um::winuser::IsIconic() function. pub fn is_minimized() -> bool {
let foreground_window: *mut winapi::shared::windef::HWND__ = unsafe { winapi::um::winuser::GetForegroundWindow() };
let is_minimized: bool = unsafe { winapi::um::winuser::IsIconic(foreground_window) } != 0;
return is_minimized;
} Still assuming that the window is in a minimized state if the window size is less than 100.0, Copy code
let ui_available_height = ui.available_height();
if ui_available_height < 100.0 {
minimized_stop_work = true;
}
if !minimized_stop_work {
ctx.request_repaint();
} This is an update sharing the current usage experience. Thanks, emilk. |
P.S. I didn't mention one observed point. When the program exits in a minimized state, the screen briefly flickers (within 0.1 seconds), appearing and disappearing, before the program terminates. |
request_repaint() if is_minimized return emilk#3321
I work finished, Pull Request. Regarding severe graphical glitches with egui emilk#3321 Changed : crates/eframe/src/native/run.rs The test results are normal.
Fix: The viewport stops working when the program is minimized. Fix: Logically, the weird parts have been normalized. **Issue :** The viewport stops working when the program is minimized. * Related #3321 * Related #3877 * Related #3985 * Closes #3972 * Closes #4772 * Related #4832 * Closes #4892 **Solution :** When `request_redraw()` is performed in Minimized state, the occasional screen tearing phenomenon has disappeared. ( Probably expected to be the effect of #4814 ) To address the issue of the `Immediate Viewport` not updating in Minimized state, we can call `request_redraw()`.
Fix: The viewport stops working when the program is minimized. Fix: Logically, the weird parts have been normalized. **Issue :** The viewport stops working when the program is minimized. * Related emilk#3321 * Related emilk#3877 * Related emilk#3985 * Closes emilk#3972 * Closes emilk#4772 * Related emilk#4832 * Closes emilk#4892 **Solution :** When `request_redraw()` is performed in Minimized state, the occasional screen tearing phenomenon has disappeared. ( Probably expected to be the effect of emilk#4814 ) To address the issue of the `Immediate Viewport` not updating in Minimized state, we can call `request_redraw()`.
Fix: The viewport stops working when the program is minimized. Fix: Logically, the weird parts have been normalized. **Issue :** The viewport stops working when the program is minimized. * Related emilk#3321 * Related emilk#3877 * Related emilk#3985 * Closes emilk#3972 * Closes emilk#4772 * Related emilk#4832 * Closes emilk#4892 **Solution :** When `request_redraw()` is performed in Minimized state, the occasional screen tearing phenomenon has disappeared. ( Probably expected to be the effect of emilk#4814 ) To address the issue of the `Immediate Viewport` not updating in Minimized state, we can call `request_redraw()`.
Title: Regarding severe graphical glitches with egui
Dear emilk,
When continuously running a program that uses the egui library on windows, there is a bug causing severe graphic glitches after about 1 to 6 hours.
Before I explain the circumstances leading to this glitch, I want to highlight another bug.
When using the above function or the native windows minimize button and then restoring the program to its original size, the frame.info().window_info.minimized remains constantly set to true. Therefore, it's impossible to determine whether the program is in a minimized state. In the minimized state, ui.available_width() slightly decreases, and ui.available_height() becomes 0.0. After restoring from the minimized state, while ui.available_width() returns to normal, sometimes ui.available_height() remains at 0.0.
I've tried to determine the exact conditions that lead to the graphic glitches. The frequency of glitches appears to be higher when restoring the program to its original size after minimizing it for over an hour. The graphical glitches also occur every few hours even without minimizing the program. When these glitches happen, it seems ui.available_height() is at 0.0. It's presumed that the glitches might be linked to the instances when, upon restoring from minimized state, ui.available_height() occasionally remains at 0.0.
Please note that this behavior isn't consistent, as it happens only every few hours. However, these are my observations so far while trying to reproduce and prevent this glitch.
Thanks.
egui Version
egui 0.22.0
egui 0.21.0
[ BUG Capture ]
[ No Bug Capture ]
Dear emilk,
I've been working for over 6 months to reproduce the issue of graphics breaking every few hours in a Windows program using the egui library. Through these efforts, I've roughly identified the reason and found a temporary way to prevent it.
When the program is minimized, the value of ui.available_height() decreases.
In the minimized state, the value of ui.available_height() seems to range between 0.0 to 20.0, depending on where the program was launched.
I tried using the method if ui.available_height() < 100.0 { return; }, but graphics still broke every few hours when restoring from a minimized state.
So,
I created the ui_available_height value using the above method and used it, but still, the graphics broke every few hours after restoring from a minimized state.
Lastly, I found a method where graphics didn't break for 2-3 days upon testing.
By assuming that it's in a minimized state when ui.available_height() is below 100.0, and by not executing ctx.request_repaint(); (RunMode::Continuous mode in egui_demo_app.exe), the screen doesn't break even when restoring from a minimized state in Windows for a prolonged period. I've successfully tested this for 2-3 days.
This method might temporarily prevent the screen from breaking. However, I'm looking forward to a fundamental solution provided by the egui library.
Thanks, emilk.
The text was updated successfully, but these errors were encountered: