ws2812 mix: add all, then divide

[nwf]

• This PR is for the dev branch rather than for master.
• This PR is compliant with the other contributing guidelines as well (if not, please describe why).
• I have thoroughly tested my contribution.

This flips the ws2812 framebuffer mix function to add all the contributions together before dividing; this allows one to, as I do, ensure that a channel stays on even in light of other operations: basefb:fill(1,1,1) ; outfb:mix(255,basefb,256/dimfactor,infb), which results in dimming that doesn't zero out color channels.

No docs changes necessary, I think.

[marcelstoer]

@Alkorin does this look reasonable to you?

[Alkorin]

What's the size of an 'int' ?
Would be better to use an uint32_t to avoid any undefined behaviour

[marcelstoer]

@nwf do you plan to address Thomas' feedback?

[nwf]

Mm, sorry, I am busy writing my PhD thesis, so time is basically, uh, zero. That said, I don't object, but I'm not sure a uint32_t is really necessary; a uint16_t would handle mixing hundreds of framebuffers without overflow, no?

[Alkorin]

As source[src].values is an uint8_t and factor an int, you already have an overflow, as only a int32_t may store the result. If factor were only an uint8_t, an uint16_t can only store the result of 1 framebuffer (255 * 255).

That's why I think int32_t is a better solution.

[nwf]

@Alkorin Erm, yes, of course. OK. I'll make the change when I get a minute.

[nwf]

Let's that on for size (thesis document done, too!)

[nwf]

@Alkorin @marcelstoer ping