-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support asyncio delayed calls in framerate_regulator #33
Comments
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 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! |
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... |
Add capability wait in event loops rather than relying on
time.sleep(...)
.ref: https://docs.python.org/3/library/asyncio-eventloop.html#delayed-calls
The text was updated successfully, but these errors were encountered: