You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently have separate loops that process incoming message events from windows, translate them into our own event structure, and push them to another thread via a crossbeam channel. This setup works, and there are nice aspects to this such as the richness of our own types that we'll likely want to keep.
There are some advantages though to handling events on the main event loop thread, specifically that dynamic priority boosts are sometimes applied to threads that receive events. By always deferring event processing to another thread, we're losing this, and when a system is under pressure this can lead to delayed event processing - also making some user state race conditions occur more often.
We can instead make use of the windows built in message dispatching to do more of the work that we're doing. There are places that we "send events to ourselves", and in these places instead of performing a write to a crossbeam channel, we can use the message sending functionality (https://learn.microsoft.com/en-us/windows/win32/winmsg/using-messages-and-message-queues).
We'll want to wrap this a little for safety, to make it easy to still have our own types, but we also might consider for some of the built-in message types instead of wrapping them, we might just extend them with our own traits for convenience.
This is a larger / more invasive change that will require a good amount of testing - not a good first issue.
The text was updated successfully, but these errors were encountered:
We currently have separate loops that process incoming message events from windows, translate them into our own event structure, and push them to another thread via a crossbeam channel. This setup works, and there are nice aspects to this such as the richness of our own types that we'll likely want to keep.
There are some advantages though to handling events on the main event loop thread, specifically that dynamic priority boosts are sometimes applied to threads that receive events. By always deferring event processing to another thread, we're losing this, and when a system is under pressure this can lead to delayed event processing - also making some user state race conditions occur more often.
We can instead make use of the windows built in message dispatching to do more of the work that we're doing. There are places that we "send events to ourselves", and in these places instead of performing a write to a crossbeam channel, we can use the message sending functionality (https://learn.microsoft.com/en-us/windows/win32/winmsg/using-messages-and-message-queues).
We'll want to wrap this a little for safety, to make it easy to still have our own types, but we also might consider for some of the built-in message types instead of wrapping them, we might just extend them with our own traits for convenience.
This is a larger / more invasive change that will require a good amount of testing - not a good first issue.
The text was updated successfully, but these errors were encountered: