Skip to content
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

Opening a glutin window on a monitor other than primary monitor for Windows crashes #1540

Open
ReallySnazzy opened this issue Dec 14, 2022 · 12 comments
Labels

Comments

@ReallySnazzy
Copy link

ReallySnazzy commented Dec 14, 2022

I've used multiple Rust projects with windowing support and managed to track the issue to Glutin. Some other projects I've tried are Neovide, WezTerm and Alacritty. By running the window example on my secondary monitor, I can get the crash as appears in the attached screenshot. Running from my primary window does not give any issue like this. When I try to close it, I get an error about the window not responding. I'm on Windows 11 64 bit. I am not able to view the console window, since I was having trouble getting the window to open on my secondary monitor while it is enabled. I had to add #![windows_subsystem = "windows"] to the window example to get it to open on my secondary monitor.

example window crash

@ReallySnazzy
Copy link
Author

Also, I don't think this issue is specific to Windows 11. If I remember correctly, then I was having this same issue with the mentioned other projects using Glutin before upgrading to Windows 11 from Windows 10.

@kchibisov
Copy link
Member

kchibisov commented Dec 14, 2022

Does plain winit work?

@ReallySnazzy
Copy link
Author

ReallySnazzy commented Dec 15, 2022

Plain Winit seems to work. I am able to resize the window and when I close it I do not get any errors about it not being responsive.

I used the example from their readme with a crate macro to indicate windows subsytem.

#![windows_subsystem = "windows"]
use winit::{
    event::{Event, WindowEvent},
    event_loop::{ControlFlow, EventLoop},
    window::WindowBuilder,
};

fn main() {
    let event_loop = EventLoop::new();
    let window = WindowBuilder::new().build(&event_loop).unwrap();

    event_loop.run(move |event, _, control_flow| {
        *control_flow = ControlFlow::Wait;

        match event {
            Event::WindowEvent {
                event: WindowEvent::CloseRequested,
                window_id,
            } if window_id == window.id() => *control_flow = ControlFlow::Exit,
            _ => (),
        }
    });
}

@ReallySnazzy
Copy link
Author

Added some logging to a file. It looks like the last event that's able to fire is Event::RedrawRequested(_).

@ReallySnazzy
Copy link
Author

ReallySnazzy commented Dec 23, 2022

Dug some more. Looks like it never returns from this function call. Added logs before and after this expression and none of the logs after this were saved.

if gl::SwapBuffers(self.hdc) == 0 {

@ReallySnazzy
Copy link
Author

ReallySnazzy commented Dec 23, 2022

Potentially related Windows bug? wxWidgets/wxWidgets#18532

Strange thing is that plenty of other applications work when opened from secondary monitor.

@ReallySnazzy
Copy link
Author

I ended up making a personal fork of Neovide to make it launch on my primary monitor. So I'll be using that as a workaround for now. I noticed several other hardware accelerated applications launching on the primary monitor by default. Not sure how common this issue is so I'll leave this issue open in case someone else wants to investigate further.

@kchibisov
Copy link
Member

If you disable vsync does it work? Remove

.set_swap_interval(&gl_context, SwapInterval::Wait(NonZeroU32::new(1).unwrap()))
.

@ReallySnazzy
Copy link
Author

ReallySnazzy commented Dec 30, 2022

If you disable vsync does it work? Remove

.set_swap_interval(&gl_context, SwapInterval::Wait(NonZeroU32::new(1).unwrap()))

.

Unfortunately, that didn't seem to fix the issue. Still gets stuck on swap_buffers. I tried commenting out this line and the surrounding lines that are commented "Try setting vsync"

@kchibisov kchibisov added the WGL label Feb 3, 2023
@ReallySnazzy
Copy link
Author

ReallySnazzy commented Dec 7, 2023

Using same displays on a new machine. Seems like the crash is not happening on this new machine. My suspicion is GPU settings, but not sure which setting specifically was responsible. New machine is also Windows 11.

@kchibisov
Copy link
Member

was it a dual GPU system btw? windows could decide to load different drivers based on monitor iirc.

@ReallySnazzy
Copy link
Author

Was a single dedicated 3060TI on previous machine. No integrated graphics on last PC. New one is similar setup with no integrated and a single dedicated 4070TI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants