[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
• A similar issue already has been reported on the squeak-vm list here: [squeak-vm] [win32] Morphic event timeStamp bug
  

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/509", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/509", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>

 

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?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/509#issuecomment-676235214", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/509#issuecomment-676235214", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>

 

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.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/509#issuecomment-685801137", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/509#issuecomment-685801137", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>

 

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-1080-mcz-td4877661.html#a4877918

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+seconds%22

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/509#issuecomment-685907914", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/509#issuecomment-685907914", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>

 

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.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/509#issuecomment-686014248", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/509#issuecomment-686014248", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>

 

Closed #509 via #518.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/509#event-3754531259", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/509#event-3754531259", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>