TFT_eSPI slow in Winduino emulation - some questions

[codewitch-honey-crisis]

I wrote a sort of shim/emulator to run Arduino code on a Windows PC so you can prototype without having to upload to hardware.

You can write windows DLL files to emulate hardware via GPIO, SPI or I2C. I wrote a generic display controller emulator that renders to a DirectX surface.

That Hello World! window is using my IoT graphics library over "SPI" to write to what it is sure is an ST7789 controller (it's not, obviously)

Anyway, I originally emulated SPI by bitbanging in both directions over my virtual GPIO, but it was very slow. I instead now export a TranferBitsSPI function from supporting hardware DLLs that eats and produces SPI data.

That's all well and good, but your library does not use the transfer(uint8_t* bytes, size_t size) function (maybe it's called transferBytes?) in SPI.h, which means it's calling that DLL exported function once for every write.

The end result is your library works, but slowly.

And I'm using the term works a bit loosely, because fonts don't work. They don't work because you're doing magic with pointers that doesn't work on 64-bit systems. I really wish you weren't - as I think there are probably other ways to do what you are doing with pgm_read_dword, but it is what it is for now.

So mainly I wanted to know why your lib doesn't transmit multiple bytes in one call, like it could with pushPixels(), for example.

Is it faster normally to do it as single transfer() calls for each byte or so?

[Bodmer]

The generic processor SPI calls are all here:
https://github.com/Bodmer/TFT_eSPI/blob/master/Processors/TFT_eSPI_Generic.h

I think I found the buffered spi transfer was slower on real hardware, so used basic transfers.

[codewitch-honey-crisis]

Yeah that header is what Winduino ends up using.

As far as why, that's fair enough. I don't really expect Winduino to be terribly fast for everything anyway, there are other ways to write to a display other than over SPI with Winduino, and they're much faster anyway. This was just so TFT_eSPI and other libs like that could be supported. :)

[codewitch-honey-crisis]

Oh hey, regarding lines like this:
char *widthtable = (char *)pgm_read_dword( &(fontdata[font].widthtbl ) ) - 32;

I know this doesn't matter in general for your use cases, but it doesn't work on 64 bit systems. It will generate compile warnings and then it will crash.

What I did to implement VLW fonts is I treated everything as 32-bit offsets from a natively sized base pointer.

How difficult would that be? I imagine it's not likely you'd spend the time on it, but I figured I'd put it out there in case I'm wrong.

[Bodmer]

The format is historical and supports a range of processors that require special instructions to access FLASH. So I am reluctant to change it.