Pump events while waiting in fps limiter

[gendlin]

Might as well chew through some input processing while waiting with nothing better to do. This will reduce the amount of work the final SDL_PumpEvents call has to do after we exit the delay loop.

[ceski-1]

The idea of using extra time in a frame to prepare for the next is interesting.

This will reduce the amount of work the final SDL_PumpEvents call has to do after we exit the delay loop.

Does calling this function at the end of the frame actually reduce the amount of time it takes for the next call?

Currently, there is either one one or two calls per frame. If a ticcmd is being built for a given frame, an SDL_PumpEvents call is made at the start. Independently, there is always a call as late as possible into the frame, just before rendering. If there was a measurable improvement, it seems like it would affect the former more than the latter.

[gendlin]

Does calling this function at the end of the frame actually reduce the amount of time it takes for the next call?

Yes, it appears to. This cuts my mouse movement "penalty" roughly in half when measuring input-to-present using the code you posted earlier (but moving the measurement to begin before the SDL_PumpEvents call). If the reason the event pump takes a long time (and it can take a surprisingly long time) is because there is a large backlog of events to get through, it makes sense that calling it more often would be beneficial if the latency of those calls can be hidden.

Also, I think the benefit may be even larger than implied by the avg input-to-present times, since large infrequent 150+ us spikes can be soaked up and hidden in the frame limiter.

If a ticcmd is being built for a given frame

Wouldn't that be relatively infrequent if I'm running at 300+ fps?

[ceski-1]

Okay, interesting. As always, some data would be nice to see.

Wouldn't that be relatively infrequent if I'm running at 300+ fps?

It would be every 1/35th second and they're expensive frames since that's when the tic-based routines are run (e.g. thinkers). So any time saved on those frames is always nice. I'm guessing the calls to SDL_PumpEvents during those frames would be reduced more than the ones just before rendering due to the length of time that passes between them relative to call you're adding.

[gendlin]

@ceski-1 Thanks. I've been meaning to add some telemetry code to get better insight into where time is being spent, but haven't quite got around to it yet. I suspect PresentMon/CapFrameX is too intrusive at high framerates to get good measurements

[ceski-1]

Thank you!