@zranger1,
I should also clarify, in the first option, the pixel super global array is managed by the engine. It’s pre-allocated, and the pixel global would likely get reset back to the proper array instance if it were accidentally changed (like pixelCount).
Each render call the array would get reset back to zeros (until some future date where a backing buffer is supported and enabled, in that case it gets updated with the last render’s data). Calls to rgb() or hsv() would write into that array. Code could also modify the array directly. At the end of render the contents of the pixel array would be sent to the LED driver.
There’s a small cost of array access, so e.g. getRed() might end up being slightly faster than pixel[0] - but my primary concern is which interface is nicer to have.
@pixie ,
Right, so you could implement cross-fading or color composition using this without pre-rendering by drawing the first color, getting the RGB, drawing the 2nd color, getting that RGB, blend both RGBs, and put back with rgb(). Once blending modes are implemented that would be even easier: draw the first color, set blend modes, draw the 2nd color. At that point getting the pixel value could still be interesting for creating additional effects or for storing the output pixel for later. Making patterns in HSV is easy, but blending 2 colors in HSV space is harder, see this post for some ideas there.