[OpenSmalltalk/opensmalltalk-vm] Win32 event generation mixes up timeGetTime() and GetMessageTime() (#509)
I'm just starting to get familiar with this repository, and I found out something interesting: On Windows, the timestamps of DND (drag and drop) events received from the VM differ by loads from the timestamps of mouse move events. For example, I recorded some event sequences where the former were circa `7140`, and the latter, just recorded a few seconds later, were `21276406`. In other cases, the difference I measured was about 57 seconds, not sure whether cause or coincidence.
Looking into `sqWin32Window.c`, this may be caused by the fact that `recordDragDropEvent()` calls `ioMicroMSecs()` which calls `timeGetTime()` from `timeapi.h` and trims the result to fit into a `SmallInteger`. On the contrary, `recordMouseEvent()`, and so `recordMouseDown()`, `recordKeyboardEvent()`, and others called from `MainWndProcW()`, use `GetMessageTime()` from `winuser.h` as time stamp which is not truncated, too.
Do we indeed need to use two different approaches, two different APIs here? This is very impractical for me as I cannot compare the timestamp of events from different sources. Would it be possible to decide for one API and one byte count? Looking forward to your feedback!
## Related sources - Besides the SmallInteger truncation, lags between timestamps from both different APIs appear to be a known problem: [StackOverflow - Lag between GetTickCount() and timeGetTime() changes between executions of my test program](https://stackoverflow.com/questions/48813245/lag-between-gettickcount-and-ti...) - A similar issue already has been reported on the squeak-vm list here: [[squeak-vm] [win32] Morphic event timeStamp bug ](http://forum.world.st/win32-Morphic-event-timeStamp-bug-td4824244.html)
No one ever having dealt with Win32 event generation before? If someone with a bit more experience than me would agree to use of the two APIs everywhere, I could try my luck. My naive proposal would be to use `GetMessageTime()` everywhere because this would reduce the extent of code to update and minimize the overall changes. Or does anyone see a good reason not keep using `timeapi.h` anywhere?
Just thinking aloud:
At the moment, there are three different time sources used in the win32 implementation:
- `Time self millisecondClockValue` based on `#utcMicrosecondClock` which counts since from 1901. - `Time eventMillisecondClock` based on `ioMSecs()` which counts since system start. (used for DnD events) - `MSG>>time` (used for most events) - `GetMessageTime()` (used for mouse events, too, but only for checking time deltas)
I just validated my assumption that `GetMessageTime()` returns values similar to `MSG>>time`, deviation could only result from a long event processing time on the VM side. As regular events are not recorded by the VM during DnD, this problem does not seem to be relevant, so I will patch `recordDragDropEvent()` to use `GetMessageTime()` now, too.
Hi Christophe, clearly we want the most simple solution that is consistent across all platforms. So yes, please feel free to harmonize the time stamps in a logical manner.
Since you're looking at time on Windows please also consider this, which is a proposal of mine for keeping the VM's microsecond clock in sync with wall time in an efficient manner while providing a monotonic microsecond clock. I haven't had time to implement it and I could really do with a collaborator to help me.
http://forum.world.st/Time-millisecondClockValue-was-The-Trunk-Morphic-mt-10...
And this link shows it's a pressing issue for Windows users: https://www.google.com/search?q=%22Windows+image+has+system+time+delay+of+40...
Hi Elliot,
clearly we want the most simple solution that is consistent across all platforms. So yes, please feel free to harmonize the time stamps in a logical manner.
While I do not totally see why across-platform consistency is relevant over different platforms (when you reopen an image on a different platform, there will be a jump in the millisecondClock anyway?), regular event timestamps appear to be consistent (time since host system start) over Windows/Linux. With my PR #518, timestamps for DnD events are consistent, too.
Also thank you for the interesting links, but I think they do not affect this PR because `GetTickCount()` only relies on the host system's clock and such is out of scope for us to sync.
Closed #509 via #518.
vm-dev@lists.squeakfoundation.org
-
Christoph Thiede -
Eliot Miranda
-
Tobias Pape