Using SetWindowsHookEx causes stuttering with high polling rate mouse

[AnAkkk]

This project sets up 3 hooks with SetWindowsHookEx, which is unfortunately causes very bad stuttering when moving the mouse if it has a high polling rate. Tested with Razer Viper 8khz, but it might also affect 1khz mice to a lesser extent.

From my testing, this is an issue with Windows itself, as even an empty hook causes the same issue. Looking at some other overlays (e.g. Steam), they hook GetMessage/PeekMessage directly to detect enabling/disabling the overlay, and then add SetWindowsHookEx hooks when the overlay is active, and remove them when it is not. That might be a solution.

I was able to fix this by subclassing the window with SetWindowLongPtr instead of using hooks https://github.com/faceit/gelectron/commit/aa39f11a34aae5f51eae5d8ec67d220553eafd8a This is not 100% tested, so there might be some use cases where it doesn't work properly, and I've commented out a part of code where it checks for "directMessageInput" as it didn't seem like it should be calling TranslateMessage directly inside the window func. It doesn't seem like the "directMessageInput" feature is really used though, it's disabled by default.

Unfortunately when subclassing the window, WM_DESTROY is never received for some games like CS:GO, because the game exits the message loop before processing such messages. gelectron seems to be very reliant on this message to shutdown properly. If it is not received, then the destructor of all the objects will be called from DLL_PROCESS_DETACH, which will cause deadlocks (when releasing DX objects) and/or crashes. Workaround https://github.com/faceit/gelectron/commit/f190c03cecb0a223245c84f8eab67bf40920ab87 although there may be a better fix.

[Nader-Sl]

@AnAkkk overlays don't get displayed at all @ faceit-client-fix

[AnAkkk]

@Nader-Sl you won't be able to use this branch directly due to other changes, I was just pointing out the specific commit.

[hiitiger]

default is use WndProc hook now