I'm writing a drawing app (think MS Paint). So it's important to get precise info about mouse movement.
However, in OpenTK, there's a problem. If I call NativeWindow.ProcessEvents, and the mouse has moved, my mousemove eventhandler gets called only *once*, with the current mouse pos. That happens even if the mouse has gone through several locations before I call ProcessEvents (meaning, the mouse device has sent several events to the computer - mouse devices usually have a high frequency).
That means my drawing app ends up having jaggy drawing. I solved that: I run an "input thread" that polls System.Windows.Forms.Cursor.Position every couple of nanosecs, and if it has changed, writes it to my own "mouse position queue". That works, but it sucks in a lot of ways.
- On singlecore PCs the CPU gets really hogged
- The use of threading is complicated to me. E.g. sometimes I get problems like thread starvation (I think), and I don't know how to solve them since I have a weak understanding of threads. I could try to debug those but I'd rather just stop using the thread hack.
I tried to make my input thread wait for mouse events, rather than constantly poll for them. I used MsgWaitForMultipleObjects from WinAPI to do that. But it never got any events - probably because Windows doesn't send events to any thread other than the GUI thread.
I think there should be a flag in OpenTK's MouseDevice, something like "bool MouseDevice.TrackAllPositions", which enables a mode like I described. It should be off by default because it would be detrimental and useless to most apps (like games). The question is, how should it be implemented?
I'm gonna keep experimenting (e.g. with a global mouse hook) but I wanted to give you a heads up.