Improve and optimize timer FD logic

[umbrageodotus]

Fixes #206 (comment)
Supercedes #257

[vaxerski]

thanks!

[umbrageodotus]

My pleasure! :3

I've also spotted another issue: lastFrame is being set on the callback, but if the callback is even so slightly late, it drifts the time completely.
Does anything else depend on lastFrame's current value? If yes, we can probably do some rounding shenanigans to round it to the correct timing, or with another, this time private, variable. If not it's easy enough: add the frame interval Ms to the value after adding the timer instead of setting it to now inside the callback.

[umbrageodotus]

@vaxerski Merging this without that fix will make the apparent problem worse. How should I proceed?

[umbrageodotus]

I've done a v1 patch for the fix. Please let me know if it's correct and/or if I should change something.

[Dregu]

Little report here too, the recent changes have made 60fps very consistent and practically eliminated frameskip from sunshine streams too. However higher framerates like 144 still run consistently slower, all tools reporting about 143.6fps, and it gets a lot worse with older hardware, not even reaching 143fps. Frameskip is of course much less noticable at higher framerates, but missing a frame every 5 seconds is not ideal. So it's much better but could still be much better.

[umbrageodotus]

I reckon the rest of the performance issues are related to polling time. Theoretically, all you'd need to do is to allow adjusting polling time for the fds and get the minimum between the default and the frame time.

Practically, though, I'm trying to make this PR scoped on non-breaking changes. So I'll leave it at this for this PR, and do that for the rest.

[umbrageodotus]

@vaxerski Ready to merge.

[vaxerski]

we can do that in a followup

[umbrageodotus]

Should I split prs tho? If the goal of this PR is optimizing timer related stuff, that's one of them.
Lmk tho

[vaxerski]

cool tnx