Process system events once per timestep interval

[Demorome]

A simple optimization for FramePacingMode.Uncapped workflows, since it'll need to deal with less redundantly accumulated input events.

It also has the benefit of removing a redundant GatherSDLEvents call for the other workflows.

[Demorome]

Hm, does it matter if system events aren't processed before all Draw calls?

In previous discussions, it was established that relying on events for determining Window size was inadequate, so it isn't needed for that, at least.

Is it a grave error to draw for a couple of waiting frames on a window that was requested to be closed, but that we didn't process that close-requested event for yet? I assume it's safe to do for at least one frame, since I've seen another engine allow rendering one last frame even after the event was processed, but I'm less sure about multiple, while the app waits for another timestep interval.

[thatcosmonaut]

This is for sure not necessary, and also will cause input latency issues. It's fine for event processing to be delayed during the catchup process.

[Demorome]

By "This", I assume you're answering my 2nd post's question, due to mentioning the catchup process?
If so, then there's no issue with the PR's proposal, in theory?