SPI graphics issues (preview 3)

TinyCLR OS
5

Big post… Sorry :frowning:

Here is the complete DrawBuffer() code :

public void DrawBuffer(Byte[] buffer, Int32 x, Int32 y, Int32 width, Int32 height, Int32 originalWidth)
        {
            BitConverter.SwapEndianness(buffer, 2);
            SendCommand(ILI9341CommandId.RAMWR);
            control.Write(GpioPinValue.High);
            spi.Write(buffer, x, y, width, height, originalWidth, 1, 1);
            BitConverter.SwapEndianness(buffer, 2);
        }

My driver has such a SetDrawWindow() method but this method is not related to the Spi call or the screen buffer, to me. It only tells the hardware where is the drawing area on the display.
This means that the data sent to the display will be displayed in this area only. Not setting this windows only means that I will indeed display everything starting at 0,0. This is expected and this is what you see on my pictures.

Setting the drawwindow e.g. at 100, 100 with a 100x100 size (width x height) and flushing the screen buffer “as is” will “move” the original picture to (100,100) and only draw a 100x100 square portion of it. I have no issue with this.

Now, if I want to draw a square portion of the Graphic.Screen, I need to calculate the offset of the data in the buffer and send data starting at this offset in the buffer. Again, this could be at 0,0 or anywhere else if I set the DrawWindow. Those are not necessarily related.
See below for another reason why those are not related.

This is to say that the “DrawWindow” is not an issue here or a reason, to me.

What I am facing is that I give the Spi call a “window” and that it sends it wrongly to the display.

I thought, (wrongly ?), that the Spi call would not send more than the amount of data calculated, as you say in your announcement post :

No. My graphics is always 240x320.

But perhaps I don’t understand how your new methods work, I dont’ know. Some examples would then be welcome.

A few lines above, I said that Graphics.Screen and display were not related. Here is an example.

I have two 128x128 displays that are close together. I want to use them as an unique 256x128 display. I create a 256x128 Graphic.Screen that contains the whole “virtual display”.
Now, in the OnFlush event, I only have to check if the horizontal coordinate is greater than 128 to choose on which display I sent the data (from a calculated offset in the buffer, of course).

Now, imagine I have a counter or a framerate indication in the bottom right corner of this 256x128 display : then I set the DrawingWindow to this lower-right corner and send only the data related to the counter.
No need to send the whole 256x128 data to only update that information.

This is why I thought your Spi overload would send only the portion of data delimited by (x, y, w, h).

Am I clear enough ? :slight_smile: