On Fri May 19 08:34:16 2023 +0000, Alexandre Julliard wrote:
In this design we create a dedicated thread to read and dispatch
Wayland events received from the compositor. If a Wayland event handler wants some code to be run in the context of a particular HWND's thread, it can add an internal event to a custom queue we have for each (GUI enabled) thread. The ProcessEvents driver callback processes internal events from that queue. In order to wake up waiting threads we use a pipe to notify about new internal events, with the read end acting as the thread's host queue fd. This is similar to how winemac.drv works. Is it really necessary to add a new event queue mechanism? Couldn't this be done for instance by using the standard message queue with internal window messages?
Hi! In addition to ensuring we process Wayland events in the proper thread, the internal per-thread event queues enable us to selectively dispatch/filter events based on the event mask in the `ProcessEvents` driver callback (see `wayland_dispatch_thread_events` in the proposal). This is needed since Wayland doesn't otherwise have any built-in support for event filtering, e.g., doesn't have something like `XCheckIfEvent`. It seems to me that such selective dispatch in the context of `ProcessEvents` handling would not be possible with a standard message queue/internal window messages approach?