osx 10.11: After getting a MouseWheel event, window freezes

[paulrouget]

On osx, with cargo run --example window, scrolling will print MouseWheel(PixelDelta(0, 0)) and then everything is frozen.

[paulrouget]

Anything I can do to help debug that?

[paulrouget]

So I'm trying to understand what's going here, and I'm a bit confused by the event polling code.

Looking at:
https://github.com/tomaka/glutin/blob/master/src/api/cocoa/mod.rs#L302

I see a loop, but, afaict, this never loops.

What is the point to call nextEventMatchingMask_untilDate_inMode_dequeue_ when it's called later in window.poll_events? (edit: nm, 2 different calls: wait_events and poll_events)

The first call uses distantFuture and doesn't empty the queue. The second one uses distantPast and does empty the queue. So is the first call here to block the call of the second call that is, I presume, non-blocking (because of distantPast)?

The problem we run into here is that in the first call, nextEventMatching + distantFuture is blocked for ever as soon as it encounters a wheel event. Using distantPast instead works. But then, we get many Awakened events, and I'm not sure that's good. Is nextEventMatching + distantPast non-blocking?

[paulrouget]

Reading more about nextEventMatchingMask, I believe the code makes sense now (beside the loop).
Using distantPast is indeed not blocking.

I don't know why nextEventMatchingMask blocks forever when getting a wheel event with distantFuture. Maybe a osx bug.

Dequeuing + distantFuture doesn't freeze though. That would mean, in wait_events, we'd need to use nextEventMatchingMask with untilDate:distantFuture and dequeue:YES, and we'd need to save the events.

[paulrouget]

This is how I think we should proceed:

• extract the NSEvent -> Event code from poll_events to its own function
• in wait_events, dequeue the NSEvent and return it as an Event

That should do it.

I'll look at this later.