High speed updates

[rssk]

First thanks for the great library! I'm updating lights at a rapid rate (30ish fps) and have noticed some interesting things:

If I set color on a particular light and try to update it rapidly, the light will seem to 'backup' updates and continue to cycle through the sent packets at a slow rate a good bit after the client code has stopped sending updates.

If I 'lock' the light such that I don't send another update until the ack callback is called, the light updates much much quicker, but still perceptibly lags from updates.

If I modify the light.js code to just send direct updates via a UDP socket bypassing the client.send queue, the updates appear to be instantaneous.

My question is what is the queuing code for in client? And would it be possible to provide some sort of direct/fast mode that forgoes the queue and immediately sends?

[ristomatti]

@rssk The queue is based on LIFX LAN API documentation which states:

Maximum recommended message transmit rate to a device: 20 per second

In node-lifx there was only a single queue for all the lights which was awfully slow with >3 lights. I've managed to speed it up a lot by creating a separate send queue for each device. At the time I was mainly focusing on multiple lights changing color as much sync as possible.

I'm currently taking time off from the computer and writing on my tablet so it's quite cumbersome for me to check the code now but your question got me thinking. I wonder if each change is always waiting for 20ms before being transmitted? If it was so, then it could be possible to alleviate the problem even within the recommends limits.

IIRC the delay is set in constants.js and you can try to lower the value at your own risk. :)