winit: MacOS can't wake up during resize, breaks timeout schemes

As the comment describes, nextEventMatchingMask:untilDate:inMode:dequeue: blocks during a resize and does not return events until the resize is complete. That includes not returning events sent via postEvent:atStart:, which means Proxy::wakeup() doesn’t actually cause run_forever() to wake up.

This property is especially unfortunate with glutin_window, which implements its own fn wait_event_timeout(&mut self, timeout: Duration) by calling run_forever() and interrupting when the timeout expires. Since it can’t interrupt, a wait_event_timeout() that wants to yield 60 fps to e.g. drive a render loop will simply hang entirely until the user is done resizing.

I’ve been experimenting with ways to get nextEventMatchingMask: to be less thorny, but another complimentary approach would be to expose a new run_until_timeout() call in addition to poll_events() and run_forever() – or perhaps to deprecate poll_events() and run_forever() in favor of run_until_timeout(Some(0)) and run_until_timeout(None). A timeout-aware API would let glutin_window pass its deadline all the way down to nextEventMatchingMask:untilDate:, avoid spawning needless timeout threads, and sidestep some of the resize-related blocking issues all at once.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 24 (6 by maintainers)

Commits related to this issue

Most upvoted comments

For posterity and because this ended up being one of the few resources about this, I’m gonna post this here too: There is a way for nextEventMatchingMask:untilDate:inMode:dequeue to not block during resizing by switching into the eventTracking run loop mode and intercepting the mouse down event on the resize areas. The obvious downside here is that one would have to implement the window resizing themselves using the mouse drag events. As @madsmtm mentioned on matrix though, aside from being more work implementing this it has other downsides e.g. potential compatibility problems and so on since this is essentially relying on undocumented quirks in appkit (but then again, what is not on macOS am I right?)