Well… delay() doesn’t ALWAYS call show, I think. It only calls it if there’s time to do a show() before the delay() time is up.
UPDATE: Nope, this is wrong. Here’s what’s right:
FastLED.delay() basically always does { delay(1); FastLED.show() }. There are two cases where it doesn’t:
(1) if the delay value == 0, then FastLED.show() is NOT called by FastLED.delay()
(2) if the delay value == 1 AND the millis() timer ticks between the first read and the second read inside delay(), then show() will NOT be called.
But if the delay value is 2 or more, FastLED.delay() calls FastLED.show().
Bottom line, I think is exactly what Andrew said at the top: “if you’re using delays and power management in your display, then you had better not use FastLED.delay().”
Or to put it another way, don’t MIX the power-managed versions of show/delay with the NON-power-managed versions. EITHER use these
show_at_max_brightness_for_power();
delay_at_max_brightness_for_power( uint16_t ms);
OR use these
FastLED.show();
FastLED.delay();
…but don’t mix them, otherwise you lose the power management controls.
In an ideal world, we’ll get the power management integrated into regular FastLED.show() and FastLED.delay(), but right now they come with a (small) performance overhead that we don’t want to impose on people who aren’t using them.We’ll get there eventually, but for now the separate APIs are the way to go.