Found something interesting while testing with win32: - The old "point" model was moving the cursor each frame (position? -> center -> position? -> center ...) - The new "box" model is moving the cursor only when the mouse is out of the box (The box size is absolutely arbitrary ... I could have divided by 4.5, by 2 or used a fixed size box, it works the same) .. The idea behind this model is to do not harass the window manager with permanent glutWarpPointer() calls, and to deal with odd window sizes, since X11 can have a different answer for "get" and "set" mouse position in such cases (dunno if I'm clear on this last point).
But what I've just discovered may be interesting for your issue: the new box model makes Windows message queue doing ... wired things. I've added raydium_log() traces for: - get delta function - message pump (a function used to request all messages to Windows since last call) - mouse move callback (glutPassiveMotionFuncCB)
With the old model, when not moving the mouse, the result is: pump, callback, delta, pump, callback, delta, ... Box model, not moving the mouse: pump, delta, pump, delta, ... (that's the point of this model) Old point model, moving the mouse, off course, changes nothing, it's the usual pump, callback, delta chain Box model, moving the mouse: pump, callback, delta, pump, callback, delta, ... It becomes like the old system. Everything is OK.
But sometimes (1 run on 5, perhaps ?), the new box models gives me, for instance: pump, callback, callback, delta, pump, delta, ... (2 callbacks on 1 frame, 0 on the next one)
WM_MOUSEMOVE messages were desynchronized, sort of. It's very wired, since Windows is supposed to erase previous mouse move messages, not stack it ! (can't find anything on MSDN about this, but found various posts on random forums stating this)
It does not happen with the old model, since glutWarpPointer() seems force something in the Windows message queue, probably while firing its own WM_MOUSEMOVE ... Or perhaps the mouse is sending too much messages sometimes (tried at different speed in the driver: 125 Hz -> 1 KHz without noticable change about this issue) so the datadump can't read quickly enough with the box model ? ... Anyway, the fact is that it works OK with the old behavior.
In your case, making the test [line 108, mouse.c] always true resolv the issue ? In this case, we'll return back to the old let's-flood-the-WM point model, that were OK with win32 and OSX, fixing 2 bugs at once, and I'll try to fix the issue from the other end: X11 trouble with odd sized windows.
|