> On 2020-09-16, at 4:37 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> Well, having the vm insert the timestamp into the event means that the timestamp can be accurate.
> 
> What we have now with the proposed changes is that the image timestamps events *immediately after the image retrieves the event via primGetNextEvent:*.

Tiny nitpick - *only* if the primitive code didn't provide it  or we're synthesizing an event. Otherwise, yes, we're already having the VM do the timestamp.

Right now (assuming I'me reading the right files!) a look through all the getevent routines suggests -

unix adds the timestamp from a call to ioMSecs, 
mac does the same except *maybe* for some tablet events?, 
Windows appears to use OS provided timestamp in the minheadless branch, or a value from GetTickCount() in the host window plugin, or something that looks like an OS provided value in sqWin32DirectInput * sqWin32Window. 
I'm sure we'll all be relieved to hear that RISC OS & Plan 9 use ioMSecs(). ;-)

So we  shouldn't ever see the timestamp being empty (for events fetched from the VM) and so shouldn't ever be manually fudging it. I'm pretty sure that is an ancient artefact of no value.

It looks like the only platform deriving the timestamp from OS event provided data is Windows. I think that there could only be a problem if synthesized events were being used, AND the time ordering had to be monotonic - do we ever sort events by timestamp? AND the clock used by the Windows to provide the stamp is not aligned with whatever we use fo ioMSecs() etc.

But otherwise, yah, no problems, the VM is already providing the timestamp and can use whatever mechanism we want. As for 64/32bit, whatever, I'm sure it can work OK. Would it be too problematic to simply make an LPI to stick into the event buffer? Sure, a bit more garbage but maybe?

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Manual Writer's Creed:  Garbage in, gospel out.