Intermediate color updates while moving around the color wheel

[WouterGritter]

Push color changes when moving your finger/mouse around the color wheel every 500 ms, instead of only when the mouse/finger gets released from the color wheel.

This real-time color changing is similar to how Philips Hue does it in their app, and it makes it feel really nice and responsive.

The implementation almost seems TOO easy, it makes me think someone has tried this before and it did not get merged for some reason. Would love to hear your feedback.

One problem I'm seeing currently is that the C code does not handle it nicely when it gets a new color while it is transition from another color. The transition is smooth for the first update, but for the second update it jumps to the second color. Then for the next update it's smooth again, and it jumps again. Could be fixed by increasing the interval that the JS code sends updates. However it might be better to update the C code.

[DedeHai]

thanks for contributing. While I like the idea, the implementation is, as you found yourself, flawed.
try what happens if you increase transition-time to 2 seconds: it will just jump from color to color every 500ms, which I think will loook awful in a lighting situation. To solve it, the code handling transitions would need a complete make-over to be able to handle "partial" transitions.

[willmmiles]

Also we've got #4158 in the pipeline for 0.16, which adds a whole bunch of neat new transition modes that definitely won't play nice with rapid FX updates. We could probably figure out some solution in the long term, eg. stacked transitions are permitted if you've got the RAM for it, but there's definitely additional work required.

I'm flagging this PR as keep for now; I think it's a nice feature that's worth revisiting when the backend can be improved to support it well.

[blazoncek]

... now imagine having transition time of 10s. 😉

Also, ESP8266, even with all the bells and whistles @willmmiles added to AWS, this rapid bombardment may bring it down.

[WouterGritter]

Okay, might be worth it to have this be a feature that's off by default then, with warnings about sending too much updates to services like AWS in the settings menu.

However, this is similar to just tapping the color wheel once or twice per second manually, which ideally should not be a huge problem as this could be done by a user trying to fine-tune the perfect color.
Edit: if it wasn't clear from the description, this was my intention with the proof-of-concept PR. I'm guessing a user does not modify the color using the color wheel often manually (at most a couple times per day), and this feature would allow for faster fine-tuning of the color in that instance. A burst of additional color update requests, but only within a small timeframe.

It could be worth adding support for an "intermediate update" in the C code. This type of update would ONLY modify the GPIO pins, and would not make any changes to external services (like mqtt, aws, even udp broadcasting). Because it always expects a final "proper" update when the user has released their thumb off of the color wheel. If we want to go that far, we can implement this system using websockets to allow for even quicker updates without much overhead from separate HTTP requests.