So, I’m trying to build a frontend for a 16x2 RGB screen attached to a Raspberry Pi. Specifically, it’s the Adafruit Pi Char RGB Plate. The problem I’m having, though it’s not exactly dire, is that sending characters to the screen is much slower when inside Mopidy compared to outside it.
Writing a single character takes about 0.012 seconds when part of Mopidy, but 0.003 seconds running outside. The difference is surprisingly noticeable in practice (0.08 seconds to print a line is fast; 0.21 seconds feels slow).
A simple test is here; if you drop it in as the frontend of an otherwise empty Mopidy extension and start Mopidy, it runs slow; if you run it directly from the command line it runs faster. Moving it to “on_start” or having it happen in another Actor doesn’t make a difference.
I’m assuming it’s because of the threading model, that my frontend’s thread is being paused for other work to happen. I don’t know if it’s at all possible to remedy this in Mopidy; can my frontend ask the other threads to pause? Any other ideas why this is happening or how to fix it?
So: I think the simplest solution is to use a separate process after all, and just communicate using WebSockets. I can make a “shim” frontend that just starts a new Python process that communicates back to Mopidy using the WebSocket interface.
Rejigging my test code to invoke a new python process with subprocess.call that then executes the same timing test in its own process fixes the slowdown completely.
It allows you to execute your code on a different process, while listening to mopidy events and interact with all the core API methods via websocket interface. For a purpose like displaying current state, track info, etc. I think it can be even a more clean approach than embedding into a mopidy extension.
