Hi Jason,
Thanks for the useful reproducible example.
Perhaps not, but you still should remove it here - all it would do in this part of the code would be to possibly delete mouse movement data.
No, it is absolutely standard practice to use this function in the way you are, to achieve real-time animation.
In my testing, the issue actually seems to be with this line:
myMouse.setPos(newPos=[0, 0])
To be honest, I’m surprised that even works: I thought it was something that could only be done with pygame rather than pyglet windows. If you remove that line, and keep the mouse continually in motion, you will no longer see the series of constant values at the start of each trial. For some reason here, this function seems to be be introducing some sort of problem in subsequently updating the mouse data buffer. Note that the issue isn’t likely one of dropping frames: your code is still running and saving values on the screen refresh cycle, or else you wouldn’t even know that there was a problem unless you checked the time as well. That is, there isn’t a function call happening here that is introducing a delay, or else you wouldn’t see the stream of values being recorded.
Re-setting the mouse position causes other issues anyway - e.g. in physical space, the mouse may be drifting across the desk because you, rather than the user, are zeroing it, in software rather than in the world, introducing a progressive mismatch that the user will eventually have to correct by picking up and the mouse and moving it back to a comfortable central position.
Instead, is it compatible with your research design that before each trial, you wait until the user brings the pointer to within some tolerance of the central point, before commencing the trial? That way the mouse is truly being kept central in physical space (i.e. on the desk) at the start of each trial.
PS this does seem somehow related to an issue dealt with earlier by @jon: