RustAudio / baseview

low-level window system interface for audio plugin UIs
Apache License 2.0
266 stars 57 forks source link

Fix: Check for remaining events in the internal X11/xcb buffers #86

Closed WeirdConstructor closed 3 years ago

WeirdConstructor commented 3 years ago

I went to #xcb on Freenode and psychon was so kind to point me to: https://docs.rs/x11rb/0.8.0/x11rb/event_loop_integration/index.html

It seems that while events are being handled new events can be queued up in the internal buffers. And so the next poll() will wait even though there are still events to be handled.

This is a race condition, so that might be why this does only occur on some systems.

psychon commented 3 years ago

I also hacked together an example that reproduces the problem and hopefully makes it clearer what is going on. Since I don't know where to leave it, I'll leave it here: https://gist.github.com/psychon/6fc6a6ed06ddfc5eea5f719aac14b7bf

The example creates a window, sends an event to the window, then does get_input_focus().get_reply(). This last part ensures that the event was already received by xcb and the FD is no longer readable. Then, I call poll() and print the information that the FD really is not readable, but poll_for_event() still returns an event afterwards.

WeirdConstructor commented 3 years ago

I want to note: This is the cause of the resizing issues I've had, so this is not only theoretical.

glowcoil commented 3 years ago

This fix looks correct to me. To make it airtight, the logic in drain_xcb_events also needs to be restructured so that poll_for_events returning None is the last thing that happens before it returns.