Investigate receiving input without using window event flow
peppy opened this issue · 2 comments
Using window events can really suck if something on the OS decides to block the macOS main thread. Any app can do this and it will cause a delay in receiving events across all apps (example ppy/osu#26604). I've hit this many times myself.
It may also be relevant on windows for key input, as we are not using raw input there (I've seen reports of some users hitting input delays on windows with similar blocking).
cc @Susko3 since you might have something to add here.
If I understand correctly, blocking the main thread only happens because we (or SDL) asks the OS for events (on Windows that would be via PeekMessage()) and that call blocks / takes a while for whatever reason. So the idea is to get (specifically) input events in another thread?
Would be useful to have a program that can generate this kind of lag. I played around in AutoHotkey and the best lag generator I could come up with is just sending a lot of mouse clicks. I'm unsure how representative this is of real-world lag, but it does spike the InputThread WndProc monitor and makes keyboard and mouse input lag.
Anyways, SDL3 recently added support for pooling Windows raw mouse input in a separate thread (libsdl-org/SDL#8756). I believe it should be possible to hook directly into these events by installing an SDL event filter/watch, like we currently do for other specific events.
It probably isn't too hard to add RAWKEYBOARD handling to SDL.
It may also be relevant on windows for key input, as we are not using raw input there (I've seen reports of some users hitting input delays on windows with similar blocking).
onWndProc in WindowsMouseHandler is only called by SDL_PumpEvents(). So it is still very much tied to the event loop.
SDL3 has added raw keyboard on windows: libsdl-org/SDL#9363. This is starting to look like a really interesting update.