Timeline for NeoPixel library performance: Adafruit vs. FastLED
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 9, 2018 at 13:29 | comment | added | Bogdan Stăncescu | That's a legitimate observation, but it depends on whether the library is throttling data bursts, or if what we're seeing is plain overhead. If it's throttling data it's all good, because all of my real-world scenario calculations will eat into the time it's currently idling. But if this is overhead then all of this is going to add up to the calculations, resulting in limited performance. I actually did track down a refresh rate throttler in the library, and hope to experiment a bit tonight. In case you're curious: github.com/FastLED/FastLED/blob/master/FastLED.cpp#L41 | |
| Jan 9, 2018 at 13:20 | comment | added | jose can u c |
Your evaluation code is fine, but probably doesn't represent a real-world use case. I've commonly seen animation code structured to have a fixed rate for the FastLED.show() command, and you have to complete all your animation steps between each frame update. That is where the fast 8-bit color and math routines are useful.
|
|
| Jan 9, 2018 at 5:32 | comment | added | Bogdan Stăncescu | Fair enough, I had ended up with the same impression – but the difference in performance for this basic test is so large I wanted to make sure I wasn't using it wrong. Thanks for taking the time to whet my appetite, though! 😊 | |
| Jan 9, 2018 at 5:25 | vote | accept | Bogdan Stăncescu | ||
| Jan 17, 2018 at 7:39 | |||||
| Jan 8, 2018 at 22:53 | history | answered | jose can u c | CC BY-SA 3.0 |