However it still feels like a very specific workaround. It's a shame we couldn't find a way of making the conversion step more efficient since it's effectively just ANDing one array with another shifted left by 3 bits.
What was your final conversion code? We could definitely do 32 bits at a time.:
// 64x16=1024
ledBuf = new Uint8Array(1024);
...
ledBuf.set(new Uint8Array(g.buffer)); // fill first part
// now use 32 bit arrays to mash 4 pixels together at once
var s = new Uint32Array(g.buffer,256);
var d = new Uint32Array(ledBuf.buffer);
s.forEach(function(x,i){return d[i]|=x<<3});
If E.mapInPlace were to provide a third argument which was the current value in the to array it'd be as simple as:
...
E.mapInPlace(s,d,(a,i,b)=>a|(b<<3));
The first option takes 0.15s on a nRF52 at 64MHz, the second takes 0.1s. Hopefully on the ESP32 that might even be a bit faster.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
I guess the relative speed depends on how many pixels you set for each frame.
The obvious thing would (I guess) be to have something inside the ArrayBuffer graphics class (so not to have setPixel) that just recalculated the address differently: https://github.com/espruino/Espruino/blob/master/libs/graphics/lcd_arraybuffer.c#L20
However it still feels like a very specific workaround. It's a shame we couldn't find a way of making the conversion step more efficient since it's effectively just ANDing one array with another shifted left by 3 bits.
What was your final conversion code? We could definitely do 32 bits at a time.:
If
E.mapInPlace
were to provide a third argument which was the current value in theto
array it'd be as simple as:The first option takes 0.15s on a nRF52 at 64MHz, the second takes 0.1s. Hopefully on the ESP32 that might even be a bit faster.