Winit: Input event timestamps

[ishitatsuyuki]

On most OSes, a timestamp is provided alongside with the input event. It could be exposed as an Option or we can just fallback to the time the poll have been executed.

[dam4rus]

Which event do you mean on Windows? You can get the timestamp of the last event returned by GetMessage with GetMessageTime. It's a bit tricky though, because it's not in system time. It also provides buffered mouse inputs through GetMouseMovePointsEx, which reports the time of each mouse event.

[ishitatsuyuki]

@dam4rus Oh well - didn't know that Windows have actually provided that, so that was an oversight on my side. Thanks for the insight.

@ZeGentzy your labels doesn't make sense from the beginning, this issue was originally about something on non-Windows; and it turns out that this is also possible on Windows. Please remove the "platform: Windows" label altogether.

[goddessfreya]

@ZeGentzy your labels doesn't make sense from the beginning, this issue was originally about something on non-Windows; and it turns out that this is also possible on Windows. Please remove the "platform: Windows" label altogether.

Sorry, my bad.

When I saw this:

On most OSes other than Windows, a timestamp is provided alongside with the input event. It could be exposed as an Option or we can just fallback to the time the poll have been executed.

I interpreted it as currently all the platforms but windows are exposing a timestamp somehow, and windows should start exposing one too, or fallback to a None if it is not available.

No clue why I read it as that. My bad.

[Osspial]

Skimming through SDL's source code, it looks like they compute their timestamp with the SDL equivalent of calling Instant::now() when an event gets delivered, which doesn't seem very different from what our users would do to get the timestamp anyway.

I'm not necessarily going to say we shouldn't add this, but what utility does exposing event timestamps have for downstream users? The fact that SDL computes the event timestamp itself rather than asking the OS makes me wary about whether or not it's necessary, but SDL doesn't always make the right call and I may very well be missing something here.

[OvermindDL1]

If the user code causes the program to freeze for, say, 3 seconds, and someone pressed, say, 'a' twice with a second in between, they'd be able to get that information is why most OS's give timestamp information with the events. I'd at least emulate that even if it would be inaccurate on windows.

[Osspial]

@OvermindDL1 Ah, that's true! I'd definitely support adding these, then.

One caveat is that, on Windows at least, GetMessageTime is only accurate to the millisecond. If we expose this through the Instant API, we'd have to document that it can't be relied on for accurate measurements.

The only question I have now is where in Event should this be exposed?

[Ralith]

IMO this should be present on every Event. A simple approach is to add the timestamp as an extra argument to the run closure. Alternatively, we could introduce something like struct EventInfo { event: Event, timestamp: Instant }.

[Osspial]

Adding a timestamp to the run closure seems like the cleanest solution to me.

[superdump]

So if I understand correctly, you’re suggesting that an additional argument be added to the run closure here: https://github.com/rust-windowing/winit/blob/master/src/event_loop.rs#L152 and that the call sites pass the time stamp. Right?

[Ralith]

That's correct.