-
Notifications
You must be signed in to change notification settings - Fork 950
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
[Windows] set_fullscreen panic (0.21) #1469
Labels
B - bug
Dang, that shouldn't have happened
C - needs investigation
Issue must be confirmed and researched
D - average
Likely as difficult as most tasks here
DS - windows
H - good first issue
Ideal for new contributors
H - help wanted
Someone please save us
P - high
Vital to have
Comments
I suspect this is the same issue producing #1400 |
We also ran into this, possibly related: subdgtl/HURBAN-Selector#129 |
filnet
pushed a commit
to filnet/winit
that referenced
this issue
Feb 26, 2020
This avoids directly sending a WM_PAINT message, which might cause buffering of RedrawRequested events. We don't want to buffer RedrawRequested events because: - we wan't to handle RedrawRequested during processing of WM_PAINT messages - state transitionning is broken when handling buffered RedrawRequested events Fixes rust-windowing#1469
8 tasks
filnet
added a commit
to filnet/winit
that referenced
this issue
Feb 28, 2020
This avoids directly sending a WM_PAINT message, which might cause buffering of RedrawRequested events. We don't want to buffer RedrawRequested events because: - we wan't to handle RedrawRequested during processing of WM_PAINT messages - state transitionning is broken when handling buffered RedrawRequested events Fixes rust-windowing#1469
Osspial
pushed a commit
to Osspial/winit
that referenced
this issue
Mar 6, 2020
This avoids directly sending a WM_PAINT message, which might cause buffering of RedrawRequested events. We don't want to buffer RedrawRequested events because: - we wan't to handle RedrawRequested during processing of WM_PAINT messages - state transitionning is broken when handling buffered RedrawRequested events Fixes rust-windowing#1469
filnet
added a commit
to filnet/winit
that referenced
this issue
Mar 6, 2020
This avoids directly sending a WM_PAINT message, which might cause buffering of RedrawRequested events. We don't want to buffer RedrawRequested events because: - we wan't to handle RedrawRequested during processing of WM_PAINT messages - state transitionning is broken when handling buffered RedrawRequested events Fixes rust-windowing#1469
Osspial
pushed a commit
that referenced
this issue
Mar 7, 2020
* On Windows, fix request_redraw() related panics These panics were introduced by 6a330a2 Fixes #1391 Fixes #1400 Fixes #1466 Probably fixes other related issues See #1429 * On Windows, replace all calls to UpdateWindow by calls to InvalidateRgn This avoids directly sending a WM_PAINT message, which might cause buffering of RedrawRequested events. We don't want to buffer RedrawRequested events because: - we wan't to handle RedrawRequested during processing of WM_PAINT messages - state transitionning is broken when handling buffered RedrawRequested events Fixes #1469 * On Windows, panic if we are trying to buffer a RedrawRequested event * On Windows, move modal loop jumpstart to set_modal_loop() method This fixes a panic. Note that the WM_PAINT event is now sent to the modal_redraw_method which is more correct and avoids an unecessary redraw of the window. Relates to but does does not fix #1484 * On Window, filter by paint messages when draining paint messages This seems to prevent PeekMessage from dispatching unrelated sent messages * Change recently added panic/assert calls with warn calls This makes the code less panicky... And actually, winit's Windoww callbacks should not panic because the panic will unwind into Windows code. It is currently undefined behavior to unwind from Rust code into foreign code. See https://doc.rust-lang.org/std/panic/fn.catch_unwind.html * add comments to clarify WM_PAINT handling in non modal loop * made redraw_events_cleared more explicit and more comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
B - bug
Dang, that shouldn't have happened
C - needs investigation
Issue must be confirmed and researched
D - average
Likely as difficult as most tasks here
DS - windows
H - good first issue
Ideal for new contributors
H - help wanted
Someone please save us
P - high
Vital to have
Windows 10 panic toggling fullscreen.
Steps to reproduce
cargo run --example fullscreen
The text was updated successfully, but these errors were encountered: