Support asyncio delayed calls in framerate_regulator

[rm-hull]

Add capability wait in event loops rather than relying on time.sleep(...).

ref: https://docs.python.org/3/library/asyncio-eventloop.html#delayed-calls

[dhrone]

I've been thinking about this request and I'm not sure Asyncio is a good candidate for this use case. You are only going to have in-effect two co-routines, one producing images and the other consuming. If the time to paint the screen is a substantial component of the duration of the period of a frame, you'll have left your generating co-routine with little time to generate the next frame.

Given the simple communications model here Generator -> display

I would propose introducing a queue and placing the display inside an OS thread.

Generator -> queue -> separate_thread(display)

As we will only be spinning up one thread it should not be a major resource hit and the queue makes sending the data to the display thread-safe.

As long as the generator can place new images in the queue faster than the frame rate (and assuming the time to refresh the display is lower than the frame rate) you should be able to get efficient resource sharing without typical multi-threaded headaches..

I also have some code I can pull in which uses a PID algorithm to smooth timing loops like this.

Let me know your thoughts.

Cheers!

[rm-hull]

I think the original motivation for this was to support an alternative programming model (asyncio) rather than for performance reasons, but i didn't put sufficient detail in the ticket...