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

Events are broken when opening multiple windows #68

Closed
tomaka opened this issue Nov 3, 2016 · 3 comments
Closed

Events are broken when opening multiple windows #68

tomaka opened this issue Nov 3, 2016 · 3 comments
Labels

Comments

@tomaka
Copy link
Contributor

tomaka commented Nov 3, 2016

Original: rust-windowing/glutin#727

@tomaka tomaka added the DS - x11 label Nov 3, 2016
jrmuizel pushed a commit to jrmuizel/winit that referenced this issue Mar 29, 2017
…alton

Stop using `NSFullSizeContentViewWindowMask` to get borderless windows,

because that disables the swap interval.

This hack is very simple but a little evil. We get the superview of the
content view, which is the `NSThemeFrame`, and install an OpenGL context
into it.  `NSThemeFrame` is a private class, but we only call public
`NSView` APIs on it here, so this seems OK in terms of being supported
by Apple going forward.

The reason for using this hack as opposed to
`NSFullSizeContentViewWindowMask` is that the latter forces the window
to be Core Animation-backed, which results in us rendering to an off
screen surface. Not only does this inject another compositor into the
system, but it also results in us rendering to an off-screen surface,
disabling the swap interval.

This depends on a `cocoa-rs` upgrade to add a binding to the `-[NSView
superview]` method.

Known issues:

* The traffic light buttons are not drawn but still function if you
  click on them. This can be worked around in browser.html.

* The top border is not rounded, although the shadow properly displays.
  This should be able to be worked around in browser.html.

* The title bar reappears if you go to full screen and then go back.
  This is the most serious issue, but I suspect it'll be fixable and
  it's better than what we have right now.

This should fix servo/servo#9431.

r? @jdm

<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/glutin/68)
<!-- Reviewable:end -->
@francesca64
Copy link
Member

I've been testing this, and all of the events have the correct window IDs.

The odd exception is a single CursorMoved event received immediately after a Focused or CursorEntered event. It has an ID that doesn't match any existing window, and a DeviceId of 3, which is notable in that it's the virtual core keyboard ID (in other words, it's a pretty badly malformed event!). However, that's not directly related to this issue, and is addressed in #372.

@knappador
Copy link

Two-window application on X11 only sends events to one of my windows, oddly the creation order doesn't matter and one window is favored to receive after it is created, though both threads are still spinning the render loop and polling.

In #252 it looks like we don't intend to support multiple event loops?

I was going to implement a single loop and transmit to all windows, but this does raise a few issues:

  • WindowBuilder.build() does not accept an EventLoopProxy or any other type to avoid creating multiple loops unless all windows are created in one thread and passed around, but even if so...
  • What is WindowEvent to one window is only seen as DeviceEvent to another and this relationship will be incorrectly stated for two windows using one loop?

Should this issue be closed?

@knappador
Copy link

@francesca64 should I expect that if I create my event loop and windows in one thread, send the windows to the caller threads, and have them wake the event loop via proxy, that the events for both windows will arrive to the single EventLoop with the correct type / window ID so that I can dispatch them across my application?

tmfink pushed a commit to tmfink/winit that referenced this issue Jan 5, 2022
madsmtm pushed a commit to madsmtm/winit that referenced this issue Jun 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

3 participants