Skip to content
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

X11 fixes #174

Merged
merged 5 commits into from
May 10, 2017
Merged

X11 fixes #174

merged 5 commits into from
May 10, 2017

Conversation

jwilm
Copy link
Contributor

@jwilm jwilm commented May 9, 2017

  • X11 poll_events actually drains queue as the documentation suggests
  • Makes EventLoop::interrupt actually wakeup the event loop. Previously it would just raise a flag without allowing run_forever to spin. This is the same behavior as the old WindowProxy::wakeup_event_loop method.

Unfortunately, EventsLoop::interrupt is also the recommend way to exit a run_forever loop from within the event handler callback. Pushing an extra event on the queue in that case is simply wasteful. Changing this would require a refactor taking one of two possible forms:

  1. Add a method in addition to interrupt intended for waking up the
    event loop
  2. Add a return type to the event callback like
    enum Continue { True, False }

which would be used in lieu of the atomic interrupt flag. With the return value here, interrupt would only be needed from other threads.

At any rate, that's out of scope for this PR. Should I open a ticket discussing this API issue?

jwilm added 4 commits May 9, 2017 09:20
It was only processing a single event per call. The docs say

> Fetches all the events that are pending, calls the callback function
> for each of them, and returns.

which suggests that was incorrect.
This is the same behavior as with WindowProxy::wakeup_event_loop in
previous versions.

Unfortunately, `EventsLoop::interrupt` is also the recommend way to exit
a `run_forever` loop from within the event handler callback. Pushing an
extra event on the queue in that case is simply wasteful. Changing this
would require a refactor taking one of two possible forms:

1. Add a method *in addition* to interrupt intended for waking up the
   event loop
2. Add a return type to the event callback like

    enum Continue { True, False }

   which would be used in lieu of the atomic interrupt flag.
This makes is possible for consumers to use cargo [replace] with the
latest Glutin.
@Ralith
Copy link
Contributor

Ralith commented May 10, 2017

LGTM. Thanks for catching those!

@jwilm
Copy link
Contributor Author

jwilm commented May 10, 2017

Thanks for the review and the recent refactoring work :)

For X11 interrupt, we can just use the root window which doesn't require
taking a lock to find.
@tomaka tomaka merged commit 4f2515f into rust-windowing:master May 10, 2017
mitchmindtree added a commit to mitchmindtree/winit that referenced this pull request Jun 24, 2017
Includes:

- Recent removal of sync (breaking change) rust-windowing#191.
- Wayland fixes: rust-windowing#190, rust-windowing#188, rust-windowing#181
- X11 fixes: rust-windowing#174, rust-windowing#178,
madsmtm pushed a commit to madsmtm/winit that referenced this pull request Jun 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants