Fix panic when dragging window between monitors of different pixels_per_point
#4088
Conversation
rustbasic
changed the title
Pixels_per_point can move quickly when moving between different screens.pixels_per_point, you can move quickly.
emilk
changed the title
pixels_per_point, you can move quickly.pixels_per_point
| if self.0.len() <= idx.0 { | ||
| self.add(clip_rect, Shape::Noop); | ||
| } |
There was a problem hiding this comment.
This shouldn't be needed unless the user does something wrong, and even then this only works if it is exactly off-by-one
There was a problem hiding this comment.
This shouldn't be needed unless the user does something wrong, and even then this only works if it is exactly off-by-one
I experienced a panic occurring when self.0.len() was 0, and there is no problem if I use this. glow_integration and wgpu_integration must also be changed. I will add that part to this commit as well.
How to reproduce panic:
- Run
examples/test_viewports. - Open all viewports.
- Close “DD -> Top D -> SS -> Top S”. (order required)
There was a problem hiding this comment.
I fail to reproduce.
In any case: try to find the root of the problem instead of adding defensive solutions
There was a problem hiding this comment.
And use RUST_BACKTRACE=1 to get stack traces
| let texture_atlas = match ctx.fonts.get(&pixels_per_point.into()) { | ||
| Some(fonts) => fonts.texture_atlas(), | ||
| None => { | ||
| ctx.fonts.iter().next() |
There was a problem hiding this comment.
This will fall back to a texture atlas for the wrong pixels_per_point, which will likely look bad. The existing check is there to help users that write egui integration to find bugs in their code.
I'd rather figure out the root cause of the bug than mask it :/
There was a problem hiding this comment.
This will fall back to a texture atlas for the wrong pixels_per_point, which will likely look bad. The existing check is there to help users that write egui integration to find bugs in their code.
I'd rather figure out the root cause of the bug than mask it :/
Don't worry, the texture atlas will be read for good pixel_per_point right away.
However, if you don't do this, a panic will occur before the texture atlas for a good pixel_per_point is read.
How to reproduce the panic is the same as the sequence shown above.
This also eliminates the root cause of the bug.
The root cause of another bug was fixed in #4128, so I didn't find it.
|
This is defensive programming that will hide the cause of the bugs instead of actually fixing them. Try to find the root of the problem instead. |
…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]>
…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]>
Closes There is on very rare occasions a case where a panic occurred #4178
Closes There is on very rare occasions a case where a panic occurred at line 152 of layers.rs #4179
Related Fix
ViewportCommand::InnerSizenot resizing viewport on Wayland (#4211) #4211This is,
pixels_per_point, you can movequickly(smooth).