-
Notifications
You must be signed in to change notification settings - Fork 868
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
Multiwindow example is broken on OS X #56
Comments
Afaict, it crashes on
|
@paulrouget what version of OS X are you on? Just tested this on OS X 10.10.5 and it seems work fine. It does use about 300% CPU though due to the hot loop for each of the 3 window threads, however it doesn't crash at any point. Edit: actually, not exactly sure why it uses up so much CPU as the loops are |
Printing the events from each of the window loops seems to show that they are just returning the |
When switching the event loop from |
I tried removing the windows 2 and 3 to see if there was some conflict between windows or something, but the behaviour was the same. Then I tried moving the |
10.12.1 |
I remember testing multi glutin windows a while back. It looked like it worked. Not sure sure if events were properly received though. And I'm not sure about CPU. I will check if this ever worked on my osx 10.11. |
When changing the example to run all windows on the main thread like this: fn main() {
let window1 = winit::WindowBuilder::new().build().unwrap();
let window2 = winit::WindowBuilder::new().build().unwrap();
let window3 = winit::WindowBuilder::new().build().unwrap();
loop {
poll_events(1, &window1);
poll_events(2, &window2);
poll_events(3, &window3);
std::thread::sleep(std::time::Duration::from_millis(100));
}
}
fn poll_events(i: i32, window: &winit::Window) {
for event in window.poll_events() {
println!("{:?} {:?}", i, &event);
match event {
winit::Event::Closed => break,
_ => ()
}
}
} it seems to behave fine, however, only It almost seems like input events are just being received by the first window that happens to poll for them, rather than only going to the currently focused window. For example, mouse coordinates are always relative to the currently focused window, however they are not necessarily received by that window ( |
@paulrouget i'm also interested in getting this working for a personal project, however I won't get time to do much digging this week. Feel free to ping me if you want me to run any tests though 👍 |
do you get window2 key events when polling window1 key events? |
Yep, no matter what window is focused, |
alright - I think the way cocoa events are pulled is wrong. I'll look into it if I ever manage to fix that crash. |
So first thing first: Then, I'm not sure (and I can't test until crash is fixed), but afaict, we use |
/cc @pcwalton can you help figuring out what's the best approach here? How do we keep |
#20 is how I think this should be solved. I haven't had a lot of feedback though. |
Merge from upstream CC rust-windowing#56 <!-- Reviewable:start --> [<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/glutin/57) <!-- Reviewable:end -->
Publish New Versions
Original: rust-windowing/glutin#618
The text was updated successfully, but these errors were encountered: