DrawBufferBytes is incorrect in JS and not flexible in all languages

[gus-ghielec]

Is this true?

DrawBuffer: Takes an array of size xy of colors int DrawBufferBytes Takes an array of xy*4 where each byte is R, G, B, A. But the implementation is not correct. It works with JS canvas that returns 32K buffer but does not work with code below.

The implementation also assumes a 128x64 display. We are introduction color 160x120 display support. This implementation needs to be clarified and adjusted on all languages.

let BrainPad = new due.DUELinkController(new SerialUSB());
await BrainPad.Connect();

let frameBuffer = new Uint32Array(128*64); 
function SetPixel(color, x, y){
    if(x<0 || x>127 || y<0 || y>63) return;
    let index = y * 128 + x;
    frameBuffer[index] = color;
}
function Clear(color){
    frameBuffer.fill(color);
}
async function Show()
{
    //await BrainPad.Display.DrawBufferBytes(frameBuffer);
    await BrainPad.Display.DrawBuffer(frameBuffer);
}

Clear(0);
while(true){
    var x = Math.random()*127;
    var y = Math.random()*63;
    SetPixel(200, x, y);
    await Show();
}

[gus-ghielec]

These pages need to be updated https://www.brainpad.com/js-framebuffer/ https://www.brainpad.com/framebuffer/

[Palomino34]

DrawBuffer: Takes an array of size xy of colors int DrawBufferBytes Takes an array of xy*4 where each byte is R, G, B, A.

They are true.

[gus-ghielec]

We should charge this to DrawBuffer(colorDepth, data) the data will always be 5:6:5 and the colorDepth determine how is the data sent to the device, 4bpp for example.

DUE lcdStream() needs to be changed to take an argument, which is color depth. Then it internally converted the incoming data to the display's native format, let's say 5:6:5 for example.

This allows the PC coffee to be uniform and gives the user there option to lose color depth in exchange of higher speeds.

[taylorza]

I think we need to enhance the I2C and SPI internal interface. Right now we are filling an entire buffer on the device before we send it to the display. For I2C we copy it to another buffer, we can save 1K RAM here if we fix this.

On SC007, we will only be able to stream 1 bit images because we do not have enough memory to create a buffer for 4 and 8 bit color.

If we can stream directly from serial to I2C or SPI then we would not care how big the buffer needs to be, we only need enough for 1 pixel so that we can convert it.

[gus-ghielec]

I thought 1bpp is all we need for sc007.

[Palomino34]

I thought 32bit RGB is much easier for users instead of 5:6:5, and this was the reason we choose 32bit data.

[gus-ghielec]

We can utility to accept ARGB and RGBA. Another option is to use 32bit as standard format for "data" in DrawBuffer(colorDepth, data) but this will never send 32bit to the device as stream accepts 5:6:5 as a max for LcdStream(16). Meaning DrawBuffer(16, data) is okay but DrawBuffer(32, data) is not.

We would still need a way to convert ARGB to RGBA. I think Python, .NET, and JS are not uniform.