Thank you, yes, that. I couldn’t find it.
And yeah, using Dan’s GridMap class is probably overkill, and the example he provided assumes that you’re also using the fancy X/Y mapping that he’s built for collections of LEDs that are NOT in an ordered grid of rows and columns, but just scattered around. So, that’s not the place to start, I agree now.
Overall, if you want the code to be workable by the largest number of people, you want to design for an 8-bit, 2K world, in which case RAM is the thing you have to watch out for all the time. Each 16x16 array of RGBs takes a whopping 768 bytes. You can have two of them, max, on your basic AVR ATmega 328 -class chips, so I’d see if you can think up a different way to do this if you want to run on those boards.
If you’re willing to say “if you want to use this cool thing, you’re going to need a bigger board”, then go for speed. A few 16x16 arrays isn’t too bad, and if you optimize the interpolation a little, I bet the speed is OK – even on 16MHz 8-bit boards.
I’m currently working on code for a 16x16 matrix that uses new Perlin/simplex noise functions, and the new color palette functions, and even with all the math going on there, it’s still clocking in faster than 30fps using an Arduino Nano (16Mhz 8-bit ATmega 328). RAM usage there is one 16x16 CRGB array for leds[], and one 16x16 uint8_t array for noise data, which I suppose I could factor out if I wanted to unroll the whole pipeline. (Hrm. Another project for another day.) Anyway, it all fits OK, and speed is OK.
Maybe the ‘basic API’ should be around an 8X8 matrix, and to output to the 16x16 you could interpolate it, filter it, scale it, zoom it, scroll it, buy it, use it, break it, fix it…