@wizard, I’m sure you’re already thinking this, but please don’t feel compelled to add features from FastLED or anywhere else unless you’re sure they fit with the architecture. It’s ok – even great – to have different tools for different jobs. Here’s how I think about Pixelblaze and FastLED…
Pixelblaze speaks the language of the problem. It abstracts away hardware detail, so you can focus on whatever you’re trying to do, which usually translates easily into code. As an interpreted language, it’s very fast if you can lean on built in functions to do your work, quite a lot slower if you’re writing multiple
for(;;) loops over an array of pixel values.
For me, optimizing on a Pixelblaze is sort of a mathematical game, like simplifying an equation. The cleaner my statement of the problem, the faster it runs.
FastLED speaks the language of the machine. Because of this design choice, and because it’s compiled, you can squeeze every last drop of performance out of a controller. It’s a great choice for algorithms that are unavoidably iterative – things that have to make multiple passes over the whole pixel array.
You own all the hardware issues right from the start though, from the cranky initialization templates, to (last I checked) no support for RGBW WS2812s, to properly scaling integer math that comes in various word lengths.
There’s the whole compile/upload cycle thing too. Even when it’s fast(ish), it still slows you down. Ever hit “Upload” and at that moment spotted a fatal bug? I have.
Bottom line: I’ll fire up Platform.io and go to the compiler when I have to, but for LED things, I’ve come to prefer Pixelblaze for its speed and fluidity of development. I love being in a time when we’ve got so many great choices though!