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
- Update fltk - Fixes #163 - Reimplements window resize - Still has problems on macOS; Resizing with the drag handle blocks the main loop. See: - https://github.com/glfw/glfw/issues/1251 - ht... — committed to parasyte/pixels by parasyte 3 years ago
- Update fltk (#169) - Fixes #163 - Reimplements window resize - Still has problems on macOS; Resizing with the drag handle blocks the main loop. See: - https://github.com/glfw/glfw/issues/125... — committed to parasyte/pixels by parasyte 3 years ago
- fix #219 (minimum stroke thickness) — committed to tmfink/winit by deleted user 5 years ago
- Merge pull request #232 from s3bk/PR fix #219 (minimum stroke thickness) — committed to tmfink/winit by pcwalton 5 years ago
- Merge next back to dev branch (#305) * refactor(windows): `begin_resize_drag` now similar to gtk's (#200) * refactor(windows): `begin_resize_drag` now similart to gtk's * fix * feat(linux): ... — committed to madsmtm/winit by deleted user 2 years ago
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:dequeueto not block during resizing by switching into theeventTrackingrun 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?)