-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Crash when changing a viewport aspect, that requires window recreation #3959
Labels
crash
crash, panic, segfault, freeze, …
egui_glow
Relates to running egui_glow on native
native-windows
Running on native Windows OS
viewports
multiple viewports, viewports API
Comments
What happens if you use the |
It crashes directly on startup on an unwrap within wgpu. Stacktrace
|
I'm getting this as well when moving a window from one monitor to another: Seems related to winits app_state module - maybe some mismatch between set_callback/clear_callback:
stacktrace
|
emilk
added a commit
that referenced
this issue
Sep 17, 2024
…per_point (#4868) Fix: panic when dragging window between monitors of different pixels_per_point This will continue to help us as we develop `egui`. I hope you agree with my defense of `panic`. * Relate #3959 * Relate #4088 * Closes #4178 * Closes #4179 There is also a way to add log if necessary. ``` log::debug!("Anti-panic behavior occurs"); ``` --------- Co-authored-by: Emil Ernerfeldt <[email protected]>
486c
pushed a commit
to 486c/egui
that referenced
this issue
Oct 9, 2024
* Fixes emilk#3959 There are two bugs racing each other here, which is why it sometimes crashes and sometimes the app just silently exists Bug 1 When the window is recreated a Destroyed event arrives (due to the Drop of the old window). The code that receives this event does not look to see if its the main viewport or a secondary one and unconditionally closes the app. The code path for other platforms is slightly different and does check. I have moved the code that handles the destroy to be in the same place and have the same behavior as the other platforms. Bug 2 At recreate time the window and winit entries of the viewport are set to None (forcin g them to be recreated). But the surface is still bound to the old window, this causes the next context switch to fail. So I simply added a viewport.gl_surface = None too, This is my first egui PR so I hope I have not broken anything. If nothing else I understand a little better how egui works.
hacknus
pushed a commit
to hacknus/egui
that referenced
this issue
Oct 30, 2024
* Fixes emilk#3959 There are two bugs racing each other here, which is why it sometimes crashes and sometimes the app just silently exists Bug 1 When the window is recreated a Destroyed event arrives (due to the Drop of the old window). The code that receives this event does not look to see if its the main viewport or a secondary one and unconditionally closes the app. The code path for other platforms is slightly different and does check. I have moved the code that handles the destroy to be in the same place and have the same behavior as the other platforms. Bug 2 At recreate time the window and winit entries of the viewport are set to None (forcin g them to be recreated). But the surface is still bound to the old window, this causes the next context switch to fail. So I simply added a viewport.gl_surface = None too, This is my first egui PR so I hope I have not broken anything. If nothing else I understand a little better how egui works.
hacknus
pushed a commit
to hacknus/egui
that referenced
this issue
Oct 30, 2024
…per_point (emilk#4868) Fix: panic when dragging window between monitors of different pixels_per_point This will continue to help us as we develop `egui`. I hope you agree with my defense of `panic`. * Relate emilk#3959 * Relate emilk#4088 * Closes emilk#4178 * Closes emilk#4179 There is also a way to add log if necessary. ``` log::debug!("Anti-panic behavior occurs"); ``` --------- Co-authored-by: Emil Ernerfeldt <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
crash
crash, panic, segfault, freeze, …
egui_glow
Relates to running egui_glow on native
native-windows
Running on native Windows OS
viewports
multiple viewports, viewports API
Description
When changing something on a viewport, that requires the recreation of the viewport window in order to apply the change, the application crashes.
I have only observed it on the glow backend, since the wgpu crashes immediately for me.
Sometimes I am getting a stack trace with a handle error and other times the application simply closes without any additional output.
The provided example changes, whether the viewport should show the close button or not (which internally requires the recreation of the viewport window).
Stacktrace
Steps to reproduce the behaviour
Platform
Example
egui_window_recreate_bug.zip
The text was updated successfully, but these errors were encountered: