SPI graphics issues (preview 3)

[Bec_a_Fuel]

How are the new methods expected to work ?

Given the following original picture (240x320, sent at once on the SPI bus ) :

A call like this one :

screen.Flush(120, 0, 60, 160);

        private static void Graphics_OnFlushEvent1(Graphics sender, Byte[] data, Int32 x, Int32 y, Int32 width, Int32 height, Int32 originalWidth)
        {
            ILI9341.DrawBuffer(data, x, y, width, height, originalWidth);
        }

The DrawBuffer is using this call :
spi.Write(buffer, x, y, width, height, originalWidth, 1, 1);

Produces this display :

If I call screen.Flush(120, 160, 120, 160); then I get this display :

What am I doing wrong ?

[Dat_Tran]

@Bec_a_Fuel

ILI9341.DrawBuffer(data, x, y, width, height, originalWidth);

Our nuget doesn’t have the API take 6 arguments. Is this your driver?

If so, make sure originalWidth and SetDrawWindow is correctly.

[Gus_Issa]

Did you change your graphics to 120x160?

[Dat_Tran]

Likely you don’t set your window in the screen. It is always start at 0,0. You need to set that if use your own driver.

[Bec_a_Fuel]

Big post… Sorry

@Dat_Tran

Our nuget doesn’t have the API take 6 arguments. Is this your driver?

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);
        }

@Dat_Tran

If so, make sure originalWidth and SetDrawWindow is correctly.

@Dat_Tran

Likely you don’t set your window in the screen. It is always start at 0,0. You need to set that if use your own driver.

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 :

@system

SPI also received a new spi.Write() overload that accepts x, y, width, height. It automatically does the needed matrix extract and sends the proper data.

@Gus_Issa

Did you change your graphics to 120x160?

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 ?

[Dat_Tran]

too long :)).

Anyway, I dont think you are right about setwindow.

If you dont set window then, let say you sent (0,0,100,100), your sceen is (240x320). Spi sent pixel 101 will be at pos x=0, y =1 (new line). But in screen it will be x = 101, y = 0 (same line).

Spi only send data in the area you Flush, how you show this array on target devices, spi doesnt know.

Also, your setwindow also not correct, I think. Try our nuget you will see different.

[Bec_a_Fuel]

@Dat_Tran

Also, your setwindow also not correct, I think. Try our nuget you will see different.

Are you really sure about that ?

[Bec_a_Fuel]

@Dat_Tran

If you dont set window then, let say you sent (0,0,100,100), your sceen is (240x320). Spi sent pixel 101 will be at pos x=0, y =1 (new line). But in screen it will be x = 101, y = 0 (same line).

Spi only send data in the area you Flush, how you show this array on target devices, spi doesnt know.

Ok.
Then I think that it’s the “OriginalWidth” parameter that led me to misunderstand the Spi call.

Going back to sleep.

[Dat_Tran]

@Bec_a_Fuel

Are you really sure about that ?

No, I could be wrong. Nothing is 100%. We dont know what we dont know. Just try our nuget to see if different.