Optimization: color_blend() variable range now determined by overloading

[DedeHai]

Removing the bool saves on code size and makes the function a tiny bit faster. Also this is a cleaner solution IMHO.

Tested the affected FX, did not notice any change.

[softhack007]

@DedeHai I've played a bit with the color_blend function, and I found some improvements

converting 8bit blend to 16bit:

(uint16_t)b << 8 : with the shift only, the max "blend16" we can achieve is 0xFF00 so if (blend == blendmax) return color2 is never taken.

To use the full range, we could use (uint16_t)b << 8) | b.

improved blend accuracy

The blend logic seems to be based on some very old FastLED code. FastLED has changed their blend8() function about 3 years ago, to avoid discontinuities and rounding errors. The new math is explained here and it seems to be numerically more stable:

https://github.com/FastLED/FastLED/blob/9176e0ff9a67365c7bd4393da52be76b6ce4a5b3/src/lib8tion/math8.h#L565

For the 8bit case, we can use the same logic - i've tested it and indeed its more accurate than the code in 0_15.

   uint8_t r3 = (((r1 << 8) | r2) + (r2 * blend) - (r1*blend) ) >> 8;

For 16bit blend, it might be trickier, because | r2 (solves rounding problems) should be either | r2<<8 or | r2<<8 | r2

[DedeHai]

with the shift only, the max "blend16" we can achieve is 0xFF00

this was fixed in the latest commit by adding a check in the inline function.

I need to take a closer look at the optimization, maybe this new version can be done the way I did with color_add() in #4138 (calculating two colors in one go)

[DedeHai]

I made some further optimizations based on the new fastLED version you proposed. In my tests, your suggested variant was a tiny bit faster when testing it on the ripple FX, my updated version uses less code so I am guessing the compile did some inlining to speed up drawCircle() in some way.
The new variant with ditching the 16bit blend and going to 8bit gives almost identical results, just the rounding is slightly different. When plotting the output of the functions, the 8bit variant is actually not any worse, at least in the cases I have taken a closer look at. When checking the ripple FX, which is the only one using the blend function apart from transitions, I could not see any difference but the new code is slightly faster.
@softhack007 Can you please check if this works as expected in your test cases?

[netmindz]

Are we good to merge this once the conflict is resolved?

[DedeHai]

there are some pending changes.
@blazoncek can you merge your changes into this PR rather than the speed_optimization PR?

edit: sorry, I think I confused this with #4256
edit2: I think this can be merged, I will resolve conflicts and do so.

[blazoncek]

I'm not sure I need to do anything regarding this PR.
However, IMO the side effect of this PR is that it will always blend using 8 bit logic which may introduce posterization. If that is of any concern is up to the users.